 |
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
|
| If you can't view the Datasheet, Please click here to try to view without PDF Reader . |
|
|
| Datasheet File OCR Text: |
| ARM966E-S microprocessor core technical manual june 2001 preliminary
ii rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. this document is preliminary. as such, it contains data derived from functional simulations and performance estimates. lsi logic has not veri?d either the functional descriptions, or the electrical and mechanical speci?ations using production parts. document db14-000111-00, first edition (june 2001) this document describes lsi logic corporation s ARM966E-S microprocessor core and will remain the of?ial reference source for all revisions/releases of this product until rescinded by an update. to receive product literature, visit us at http://www.lsilogic.com. lsi logic corporation reserves the right to make changes to any products herein at any time without notice. lsi logic does not assume any responsibility or liability arising out of the application or use of any product described herein, except as expressly agreed to in writing by lsi logic; nor does the purchase or use of a product from lsi logic convey a license under any patent rights, copyrights, trademark rights, or any other of the intellectual property rights of lsi logic or third parties. copyright 1999?001 by lsi logic corporation. all rights reserved. trademark acknowledgment lsi logic logo design. g10, gigablaze, coreware, flexstream, and right-first- time are trademarks or registered trademarks of lsi logic corporation.arm is a registered trademark of arm ltd., used under license. all other brand and product names may be trademarks of their respective companies. eh ARM966E-S microprocessor core iii rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. preface this book is the primary reference and technical manual for the ARM966E-S microprocessor core. it contains a complete functional description of the core and describes the main features of the microarchitecture. audience this document assumes that you have some familiarity with microprocessors and related support devices. the people who bene? from this book are: ? engineers and managers who are evaluating the processor for possible use in a system ? engineers who are designing the processor into a system organization this document has the following chapters: ? chapter 1, introduction , provides an overview of the ARM966E-S microprocessor core and the lsi logic coreware program. ? chapter 2, signal descriptions , describes all of the external interface signals. ? chapter 3, programmer s model , discusses the memory model and operating modes of the ARM966E-S, and describes its register set. ? chapter 4, exception processing , describes the events that cause the ARM966E-S exceptions and discusses how the ARM966E-S handles them. ? chapter 5, ahb interface unit , describes the operation of the advanced high-performance bus interface unit. iv preface rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. ? chapter 6, write buffer , describes the internal write buffer. ? chapter 7, system controller , describes the internal coprocessor 15 block, which the cpu uses to control the write buffer and instruction and data rams. ? chapter 8, tightly coupled ram , describes the two built-in rams: the instruction ram and the data ram. ? chapter 9, external coprocessor interface , describes the external coprocessor interface through which additional on-chip coprocessors connect. ? chapter 10, debug , describes the operation of the ARM966E-S debug interface, which is based on the ieee std. 1149.1-1990. ? chapter 11, test methodology , discusses the available test methods. ? appendix a, arm9e-s enhanced instructions , describes the enhancements to the arm9e-s instruction set. related publications arm946e-s microprocessor core with cache technical manual, document no. db14-000104-00 standard test access port and boundary scan architecture , ieee standard 1149.1-1990 arm940t datasheet , arm ltd., document no. arm ddi 0092a-04 arm9 architecture reference manual , arm ltd., document no. arm ddi 0100 arm9e-s technical reference manual , arm ltd., document no. arm ddi 0165 arm hurricane engineering speci?ation ahb speci?ation (rev. 2.0) , arm ltd., document no. arm ihi 0011 conventions used in this manual the ?st time a word or phrase is de?ed in this manual, it is italicized. preface v rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. the word assert means to drive a signal true or active. the word deassert means to drive a signal false or inactive. hexadecimal numbers are indicated by the pre? ?x ?or example, 0x32cf. binary numbers are indicated by the pre? ?b ?or example, 0b0011.0010.1100.1111. vi preface rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. ARM966E-S microprocessor core vii rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. contents chapter 1 introduction 1.1 overview 1-1 1.2 block diagram description 1-2 1.2.1 arm9e-s processor core 1-3 1.2.2 system controller 1-4 1.2.3 cp15 system control coprocessor 1-4 1.2.4 address decoders 1-4 1.2.5 instruction and data rams 1-4 1.2.6 dma interface 1-5 1.2.7 ahb interface unit and write buffer 1-5 1.2.8 external coprocessor interface 1-5 1.2.9 jtag and debug port 1-5 1.2.10 embedded trace module interface 1-6 1.3 feature summary 1-6 1.4 coreware program 1-6 chapter 2 signal descriptions 2.1 ahb interface 2-3 2.2 coprocessor interface 2-8 2.3 instruction ram signals 2-10 2.4 data ram signals 2-10 2.5 dma signals 2-12 2.6 debug signals 2-14 2.7 etm interface signals 2-16 2.8 miscellaneous signals 2-20 2.9 initialization control signals 2-21 2.10 atpg scan control signals 2-21 viii contents rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. chapter 3 programmer s model 3.1 about the programmer s model 3-1 3.2 data abort model 3-2 3.3 data types 3-2 3.4 processor modes 3-3 3.5 cp15 instruction format 3-4 3.6 memory map 3-5 3.7 registers 3-5 3.7.1 cpu registers 3-6 3.7.2 cp15 registers 3-9 chapter 4 exception processing 4.1 overview 4-1 4.2 exception flow 4-2 4.3 exception descriptions 4-4 4.3.1 reset exception 4-4 4.3.2 unde?ed instruction execution 4-4 4.3.3 software interrupt exception 4-5 4.3.4 prefetch abort (instruction fetch memory abort) 4-5 4.3.5 data abort (data access memory abort) 4-6 4.3.6 irq (interrupt request) exception 4-7 4.3.7 fiq (fast interrupt request) exception 4-7 chapter 5 ahb interface unit 5.1 overview 5-1 5.2 ahb interface signals 5-2 5.2.1 transfer types 5-3 5.2.2 burst types 5-4 5.2.3 control signals 5-5 5.2.4 data buses 5-8 5.2.5 endianess 5-10 5.3 ahb clocking 5-11 5.4 ahb operation 5-11 5.5 basic transfers 5-12 5.6 burst operations 5-15 5.6.1 early burst termination 5-15 contents ix rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. 5.6.2 burst operation example 5-15 5.7 slave transfer responses 5-16 5.7.1 two-cycle response 5-17 5.7.2 error response 5-18 5.7.3 retry responses 5-19 5.7.4 split responses 5-19 chapter 6 write buffer 6.1 introduction 6-1 6.2 normal operation 6-2 6.3 full write buffer 6-2 6.4 unbuffered writes 6-3 6.5 read-lock-write 6-3 6.6 read to write-posted address 6-3 6.7 write buffer nonrecoverable error and abort conditions 6-3 chapter 7 system controller 7.1 operation 7-1 7.2 clock control 7-2 chapter 8 tightly coupled ram 8.1 tightly coupled memory (tcm) overview 8-1 8.2 ARM966E-S sram requirements 8-1 8.3 enabling the sram 8-2 8.3.1 using initram to enable sram 8-2 8.3.2 using cp15 control register to enable sram 8-3 8.4 ARM966E-S sram wrapper 8-5 8.5 example sram interfaces 8-6 8.5.1 onesegx32 8-7 8.5.2 foursegx32 8-7 8.5.3 foursegx8 8-8 chapter 9 external coprocessor interface 9.1 overview 9-1 9.2 coprocessor instruction execution 9-2 9.2.1 ldc/stc instructions 9-2 x contents rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. 9.2.2 mcr/mrc instructions 9-5 9.2.3 interlocked mcrs 9-6 9.2.4 cdp instructions 9-7 9.3 privileged instructions 9-8 9.4 stalling and interrupts 9-9 chapter 10 debug 10.1 debug systems 10-1 10.1.1 the debug host 10-2 10.1.2 the protocol converter 10-2 10.1.3 debug target 10-3 10.2 about the debug interface 10-4 10.2.1 stages of debug 10-5 10.2.2 clocks 10-5 10.3 scan chain 15 10-6 10.4 breakpoints, watchpoints, and external debug requests 10-8 10.4.1 entry into debug state on breakpoint 10-9 10.4.2 breakpoints and exceptions 10-10 10.4.3 watchpoints 10-11 10.4.4 watchpoints and exceptions 10-13 10.4.5 debug request 10-13 10.4.6 actions of the arm9e-s core in debug state 10-13 10.5 arm9e-s clock domains 10-14 10.6 determining the core and system states 10-14 10.7 about the embeddedice-rt logic 10-14 10.8 disabling the embeddedice-rt logic 10-16 10.9 the debug communications channel 10-16 10.9.1 debug communication channel registers 10-17 10.9.2 debug communications channel status register 10-17 10.9.3 communications channel monitor mode debug status register 10-18 10.9.4 using the communications channel 10-19 10.10 real-time debug 10-20 chapter 11 test methodology 11.1 scan insertion 11-1 contents xi rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. 11.2 rambist 11-1 appendix a arm9e-s enhanced instructions index customer feedback figures 1.1 ARM966E-S block diagram 1-3 2.1 ARM966E-S signal diagram 2-2 3.1 coprocessor instruction format 3-4 3.2 ARM966E-S memory map 3-5 3.3 cpu register organization 3-6 3.4 program status registers (cpsr and spsr) format 3-8 5.1 multiplexer interconnection 5-2 5.2 transfer type examples 5-4 5.3 ahb clock relationships 5-11 5.4 simple transfer 5-13 5.5 transfer with wait states 5-14 5.6 multiple transfers 5-14 5.7 incrementing bursts with unde?ed lengths 5-16 5.8 transfer with retry response 5-18 5.9 error response 5-18 8.1 sram read cycle 8-2 8.2 ARM966E-S sram hierarchy 8-6 8.3 onesegx32 interface 8-7 8.4 foursegx32 interface 8-8 8.5 foursegx8 interface 8-10 9.1 clk and cpclken timing 9-2 9.2 ldc/stc cycle timing 9-3 9.3 mcr/mrc cycle timing 9-6 9.4 interlocked mcr 9-7 9.5 late cancelled cdp 9-8 9.6 privileged instructions 9-9 9.7 stalling and interrupts 9-10 xii contents rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. 10.1 typical debug system 10-2 10.2 arm9e-s processor and debug logic 10-3 10.3 clock synchronization logic 10-6 10.4 breakpoint timing 10-10 10.5 watchpoint entry with data processing instruction 10-11 10.6 watchpoint entry with branch 10-12 10.7 the arm9e-s, tap controller, and embeddedice-rt 10-15 10.8 debug communications channel status register 10-17 10.9 coprocessor 14 debug status register format 10-18 tables 3.1 supported data types 3-2 3.2 arm9e-s processor modes 3-3 3.3 instruction format field descriptions 3-4 3.4 mode bits 3-9 3.5 cp15 register map 3-9 3.6 core control instructions 3-12 3.7 register 13, trace process identi?r 3-14 3.8 cp15 rambist register map 3-14 4.1 exception processing modes 4-2 4.2 exception priority order 4-2 5.1 transfer type encoding 5-3 5.2 burst signal encoding 5-5 5.3 size encoding 5-6 5.4 protection signal encoding 5-7 5.5 active byte lanes for a 32-bit little-endian data bus 5-9 5.6 active byte lanes for a 32-bit big-endian data bus 5-10 10.1 scan chain 15 addressing mode bit order 10-6 10.2 mapping of scan chain 15 address field to cp15 registers 10-7 10.3 debug state figure notations 10-9 10.4 cp14 register map 10-17 ARM966E-S microprocessor core technical manual 1-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 1 introduction this chapter introduces the ARM966E-S microprocessor core. this chapter contains the following sections: ? section 1.1, ?verview ? section 1.2, ?lock diagram description ? section 1.3, ?eature summary ? section 1.4, ?oreware program 1.1 overview the ARM966E-S microprocessor core is a synthesizable macrocell that integrates the arm9e-s 32-bit processor, an instruction ram, a data ram, a write buffer, and an ahb bus interface. the ARM966E-S implements the arm architecture v5t, which supports both the 32-bit arm and 16-bit thumb instruction sets, allowing you to trade off between high performance and high code density. additionally the arm9e-s processor core provides an arm9e-s instruction extension and an enhanced multiplier for increased dsp performance. the ahb bus interface eases connection to cached and sram-based memory systems. the ARM966E-S supports the arm debug architecture and includes logic to assist in both hardware and software debug. it supports nonstopping hardware debug, which allows critical exception handlers to execute while debugging the system. the ARM966E-S provides real-time trace and supports external coprocessors. 1-2 introduction rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 1.2 block diagram description figure 1.1 shows a block diagram of the ARM966E-S. the main functional blocks are: ? arm9e-s processor core ? system controller ? cp15 system control coprocessor ? instruction ram ? data ram ? dma interface to data ram ? address decoders ? write buffer ? ahb interface ? external coprocessor interface ? jtag and debug port ? embedded trace module interface these modules are brie? described following the block diagram. they are described in more detail in the subsequent chapters of this manual. block diagram description 1-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 1.1 ARM966E-S block diagram 1.2.1 arm9e-s processor core the arm9e-s processor core has a harvard bus architecture with separate instruction and data interfaces. this design allows concurrent instruction and data accesses, and greatly reduces the cycles per instruction of the processor. for optimal performance, single-cycle memory accesses for both interfaces are required, although the core can be stalled for nonsequential accesses or slower memory systems. ahb bus interface unit and write buffer instruction sram dout addr din data sram dout addr din system control coprocessor (cp15) external coprocessor interface ia arm9e-s instr rdata da wdata system controller etm interface dma interface dma controller ahb peripherals coprocessors core etm 1-4 introduction rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the processor is implemented using a ve-stage pipeline: ? instruction fetch (f) ? instruction decode (d) ? execute (e) ? data memory access (m) ? register write (w) arm implementations are fully interlocked, so that software functions identically across different implementations without concern for how the pipeline is affected. 1.2.2 system controller the system controller oversees the interactions between the instruction ram, data ram, and the bus interface unit. it controls internal arbitration between the blocks and stalls the appropriate blocks when required. 1.2.3 cp15 system control coprocessor the processor core uses a set of registers in the cp15 coprocessor to control the functionality of the rams and the write buffer. these registers are accessed using the coprocessor instructions mcr and mrc. 1.2.4 address decoders the address decoders determine whether a memory request accesses the internal ram or the advanced high-performance bus (ahb) interface. the address decoders provide a hit/miss indication to the system controller, which then either stalls the core if an ahb read or unbuffered write access is required or allows execution to continue if the access hits the ram or is a buffered write. 1.2.5 instruction and data rams the ARM966E-S incorporates internal instruction and data memories to allow high-speed operation without incurring the performance penalty of accessing the system bus or the die size penalty of a cached processor. block diagram description 1-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the instruction and data rams each consist of blocks of asic library compiled ram. the ram sizes can be of any size up to 64 mbytes. the instruction and data memories can have unique sizes. 1.2.6 dma interface the direct memory access (dma) interface allows an external device direct access to the ARM966E-S data ram. if a single-port data ram is used, then the dma interface stalls the ARM966E-S microprocessor core during the dma transfer. if a dual-port data ram is used, then the dma interface does not stall the ARM966E-S during the dma transfer. 1.2.7 ahb interface unit and write buffer the ahb is a new generation of amba bus, which meets the requirements of high-performance synthesizable designs. the ahb interface unit arbitrates between the external bus transaction sources within the ARM966E-S. it stalls all other accesses until the current request has been completed. the ahb interface unit supports the following types of transactions: burst transfers, split transactions, single-cycle bus master handovers, single clock edge operations, and non-3-state implementations. the write buffer is a 12-entry fifo. it increases system performance. 1.2.8 external coprocessor interface the ARM966E-S supports the connection of coprocessors through the external coprocessor interface. all types of arm coprocessor instructions are supported. coprocessors determine the instructions they need to execute using a pipeline follower in the coprocessor. 1.2.9 jtag and debug port the ARM966E-S debug interface is based on ieee std. 1149.1-1990. it can stop the processor core on a given instruction fetch (breakpoint), data access (watchpoint), or external debug request. the jtag-style serial interface can serially insert instructions into the pipeline of the core without using the external data bus. 1-6 introduction rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 1.2.10 embedded trace module interface this interface connects to an external embedded trace module (etm). the etm provides a high-speed port for tracing of the processor core in real time. 1.3 feature summary this section lists the key features of the ARM966E-S microprocessor core: ? arm9e-s processor core ? instruction and data rams with independent sizes up to 64 mbytes ? dma interface to data ram ? arm advanced high-performance bus (ahb) interface unit with write buffer write buffer depth: 16 words at up to four addresses burst transfers split transactions ? external coprocessor interface ? system controller arbitrates between instruction and data memories and ahb ? embedded trace module provides a real-time trace capability 1.4 coreware program an lsi logic core is a fully de?ed, optimized, and reusable block of logic. it supports industry-standard functions and has prede?ed timing and layout. the core is also an encrypted rtl simulation model for a wide range of vhdl and verilog simulators. the coreware library contains an extensive set of complex cores for the storage, communications, consumer, and computer markets. the library consists of high-speed interconnect functions such as the gigablaze g10 core, dsps, mpeg-2 decoders, a pci core, and many more. coreware program 1-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the library also includes megafunctions or building blocks, which provide useful functions for developing a system on a chip. through the coreware program, you can create a system on a chip uniquely suited to your applications. each core has an associated set of deliverables, including: ? encrypted rtl or c simulation models for both verilog and vhdl environments ? a system veri?ation environment (sve) for rtl-based simulation ? netlists for full timing simulation ? complete documentation ? lsi logic flexstream design support the lsi logic flexstream design solution provides seamless connectivity between products from leading electronic design automation (eda) vendors and the lsi logic manufacturing environment. standard interfaces for formats and languages such as vhdl, verilog, waveform generation language (wgl), physical design exchange format (pdef), and standard delay format (sdf) allow a wide range of tools to interoperate within the lsi logic flexstream design environment. in addition to design capabilities, full scan automatic test pattern generation (atpg) tools and lsi logic's specialized test solutions can be combined to provide high-fault coverage test programs that assure a fully functional design. because your design requirements are unique, lsi logic is ?xible in working with you to develop your system-on-a-chip coreware design. three different work relationships are available: ? you provide lsi logic with a detailed speci?ation and lsi logic performs all design work. ? you design some functions while lsi logic provides you with the cores and megafunctions, and lsi logic completes the integration. ? you perform the entire design and integration, and lsi logic provides the core and associated deliverables. whatever the work relationship, lsi logic s advanced coreware methodology and asic process technologies consistently produce right-first-time silicon. 1-8 introduction rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. ARM966E-S microprocessor core technical manual 2-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 2 signal descriptions this chapter describes the external signals of the ARM966E-S microprocessor core. the descriptions are categorized according to the interface. the signal descriptions are listed alphabetically by mnemonic within each interface. in the descriptions that follow, the verb assert means to drive true or active. the verb deassert means to drive false or inactive. this chapter contains the following sections: ? section 2.1, ?hb interface ? section 2.2, ?oprocessor interface ? section 2.3, ?nstruction ram signals ? section 2.4, ?ata ram signals ? section 2.5, ?ma signals ? section 2.6, ?ebug signals ? section 2.7, ?tm interface signals ? section 2.8, ?iscellaneous signals ? section 2.9, ?nitialization control signals ? section 2.10, ?tpg scan control signals figure 2.1 provides a signal summary for the ARM966E-S. 2-2 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 2.1 ARM966E-S signal diagram haddr[31:0] hburst[2:0] hbusreq hgrant hlock hprot[3:0] hrdata[31:0] hready hresetn hresp[1:0] hsize[2:0] htrans[1:0] hwdata[31:0] hwrite ahb interface coprocessor interface chsde[1:0] chsex[1:0] cpclken cpdin[31:0] cpdout[31:0] cpinstr[31:0] cplatecancel cppass cptbit ncpmreq ncptrans instruction ram iaddr[23:0] ienable irdata[31:0] iwdata[31:0] iwe[3:0] noiram daddr[23:0] denable drdata[31:0] dwdata[31:0] dwe[3:0] nodram daddr2[23:0] denable2 drdata2[31:0] dwdata2[31:0] dwe2[3:0] data ram dmaa[25:0] dmad[31:0] dmaenable dmamas[1:0] dmanrw dmardata[31:0] dmaready dmawait dmanreq dma commrx commtx dbgack dbgdewpt dbgen dbgext[1:0] dbgiebkpt dbginstrexec dbgir[3:0] dbgntdoen dbgntrst dbgrng[1:0] dbgrqi cbgscreg[4:0] dbgsdin dbgsdout dbgtapsm[3:0 dbgtcken dbgtdi dbgtdo dbgtms edbgrq debug bigendout clk hclken nfiq nirq miscellaneous ARM966E-S ahb interface 2-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 2.1 ARM966E-S signal diagram (cont.) 2.1 ahb interface haddr[31:0] address bus out output the ARM966E-S drives the ahb address on haddr[31:0]. etmbigend etmchsd[1:0] etmchse[1:0] etmda[31:0] etmdabort etmdbgack etmdmas[1:0] etmdmore etmdnmreq etmdnrw etmdseq etmen etmhivecs etmia[31:1] etmid31to25[31:25] etmid15to11{15:11] etminmreq etminstrexec etmiseq etmitbit etmlatecancel etmnwait etmpass etmrdata[31:0] etminstrvalid etmprocid[31:0] etmprocidwr fifofull tapid[31:0] etm interface initram vinithi scanen si so initialization control atpg scan control ARM966E-S etmrngout[1:0] etmwdata[31:0] 2-4 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. hburst[2:0] burst type output this output indicates whether the transfer forms part of a burst. the ARM966E-S generates burst types of single and incr only. hbusreq bus request output hbusreq is a signal from the ARM966E-S to the bus arbiter. a high in this output indicates that the core requires the bus. hgrant bus grant input a high on this signal indicates the ARM966E-S is currently the highest priority master. ownership of the address/control signals changes at the end of a transfer when hready is high. a master gets access to the bus when both hready and hgrant are high. hlock locked transfer output when hlock is high, it indicates that the ARM966E-S requires locked access to the bus, and that no other masters should be granted the bus until hlock is low. hlock is asserted when the ARM966E-S is executing the swap instruction. hprot[3:0] protection control output this output provides additional information about a bus access. hprot[3:0] are primarily intended for use by any module that implements some level of protection. hburst[2:0] burst type description 000 single single transfer 001 incr incrementing burst of unspeci?d length 010?11 reserved not supported ahb interface 2-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the signals indicate whether the transfer is an opcode fetch or data access, and whether the transfer is a supervisor mode access or user mode access. note that for the ARM966E-S, hprot3 is forced low (noncacheable). hrdata[31:0] read data bus input this bus transfers data from the bus slaves to the ARM966E-S during read operations. the ARM966E-S has a 32-bit wide data bus. the width can be easily extended outside the core to allow for higher bandwidth operation. hready transfer done input when high, the hready signal indicates the transfer on the bus has ?ished. drive this signal low to extend a transfer. note: slaves on the bus require hready to be both an input and an output. hresetn reset input this input is the active-low system reset. hresp[1:0] transfer response input hresp[1:0] provide additional information on the status of a transfer. when a slave must insert a number of wait hprot3 cacheable hprot2 bufferable hprot1 supervisor hprot0 data/opcode description 0 opcode fetch 1 data access 0 user access 1 supervisor access 0 not bufferable 1 bufferable 0 not cacheable 2-6 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. states prior to decoding what response to give, then it must drive the response to okay. hsize[2:0] transfer size output this output indicates the size of the transfer, which is typically byte (8 bits), halfword (16 bits), or word (32 bits). hresp[1:0] transfer response description 00 okay when hready is high, the transfer has completed. 01 error this response shows an error has occurred. the error condition must be signaled to the bus master so that it is aware the transfer was unsuccessful. a two-cycle response is required for an error condition. 10 retry the retry response shows the transfer is not complete, so the bus master should retry the transfer. the master will continue to retry the transfer until it completes. a two-cycle retry response is required. 11 split the split response indicates the transfer has not yet completed successfully. the bus master must retry the transfer when it is next granted access to the bus. the slave will request access to the bus on behalf of the master when the transfer can complete. a two-cycle split response is required. hsize[2:0] transfer size description 000 8 bits byte 001 16 bits halfword 010 32 bits word 011?11 reserved ahb interface 2-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. htrans[1:0] transfer type out output this output indicates the current transfer type. hwdata[31:0] write data bus output this bus transfers data from the master to the bus slaves during write operations. the width can be extended external to the core to allow for higher bandwidth operation. hwrite transfer direction out output when hwrite is high, the transfer is a write. when hwrite is low, the transfer is a read. htrans[1:0] transfer type description 00 idle no data transfer required. 01 busy used to insert an idle cycle in the middle of a burst of transfers. 10 nonsequential indicates ?st transfer of a burst or single transfer. 11 sequential the control information is identical to the previous transfer. the address is equal to the address of the previous transfer plus the size (in bytes). for wrapping bursts, the address of the transfer wraps at the address boundary equal to the size (in bytes) multiplied by the number of beats in the transfer (either 4, 8, or 16). 2-8 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 2.2 coprocessor interface chsde[1:0] coprocessor handshake decode input these inputs are the handshake signals from the decode stage of the coprocessor s pipeline follower. chsex[1:0] coprocessor handshake execute input these inputs are the handshake signals from the execute stage of the coprocessor s pipeline follower. cpclken coprocessor clock enable output this clock enable controls the timing of the coprocessor interface. it is used in conjunction with clk to effectively run the coprocessor at a higher frequency than the data bus. cpdin[31:0] coprocessor data in input this 32-bit bus is the coprocessor data bus for transferring mrc and stc data from the coprocessor to the ARM966E-S. cpdout[31:0] coprocessor data out output this 32-bit bus is the coprocessor data bus for transferring data to the coprocessor. chsde[1:0] encoding 10 absent 00 wait 01 go 11 last chsex[1:0] encoding 10 absent 00 wait 01 go 11 last coprocessor interface 2-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. cpinstr[31:0] coprocessor instruction output this 32-bit bus is the coprocessor instruction data bus for transferring instructions to the pipeline follower in the coprocessor. cplatecancel coprocessor late cancel output when cplatecancel is high during the ?st memory cycle of a coprocessor instruction execution, the coprocessor instruction must be cancelled without updating any internal state. this signal is asserted only in cycles where the previous instruction accessed memory and a data abort occurred. cppass coprocessor pass output a high on this signal indicates that there is a coprocessor instruction in the execute stage of the pipeline that should be executed. cptbit coprocessor interface in thumb state output when cptbit is high, the coprocessor interface is in thumb state (16-bit instructions); otherwise the interface supports 32-bit instruction execution. ncpmreq not coprocessor memory request output when ncpmreq is low on a rising clk edge and cpclken is high, the instruction on cpinstr must enter the coprocessor pipeline follower s decode stage, and the instruction previously in the pipeline follower s decode stage should enter its execute stage. ncptrans not coprocessor translate output when ncptrans is low, the coprocessor interface is in a nonprivileged state. when ncptrans is high, the coprocessor interface is in a privileged state. the coprocessor should sample this signal on every cycle when determining the coprocessor response. refer to section 3.4, ?rocessor modes, for a description of the privileged and nonprivileged (user) modes. 2-10 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 2.3 instruction ram signals iaddr[23:0] instruction ram address output this 24-bit bus contains the instruction ram address. addressing is performed on word boundaries. ienable word-based instruction chip enable output the ARM966E-S asserts this output high to indicate the instruction ram data bus is enabled. irdata[31:0] instruction ram read data input this 32-bit bus contains data read from the instruction ram. iwdata[31:0] instruction ram write data output this 32-bit bus contains write data for the instruction ram. iwe[3:0] byte-based instruction write enable output the ARM966E-S asserts these outputs high to enable writes to the instruction ram. noiram instruction ram present input the ARM966E-S asserts noiram high to indicate the instruction ram is not present and thus instruction ram decoding is disabled. noiram asserted low indicates instruction ram is present, which enables instruction ram decoding. 2.4 data ram signals the data ram interface supports both single-port and dual-port rams. when single-port rams are used, the ARM966E-S stalls during dma transfers. when dual-port rams are used, the ARM966E-S does not need to be stalled during dma transfers. iwe bit function iwe3 write enable for iwdata[31:24] iwe2 write enable for iwdata[23:16] iwe1 write enable for iwdata[15:8] iwe0 write enable for iwdata[7:0] data ram signals 2-11 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the ARM966E-S uses the signals described below to access the data ram for both single-port and dual-port ram implementations. the dma interface shares these signals with the ARM966E-S for single-port ram implementations. daddr[23:0] data ram address output this 24-bit bus contains the data ram address. addressing is performed on word boundaries. denable word based data chip enable output the ARM966E-S asserts this output high to indicate the data ram data bus is enabled. drdata[31:0] data ram read data input this 32-bit bus contains data read from the data ram. dwdata[31:0]data ram write data output this 32-bit bus provides write data to the data ram. dwe[3:0] byte based data write enable output the ARM966E-S asserts these outputs high to enable writes to the data ram. nodram data ram present input the ARM966E-S asserts nodram high to indicate data ram is not present and thus data ram decoding is disabled. nodram asserted low indicates data ram is present, which enables data ram decoding. the dma interface uses the signals described below to access only the second port of a dual-port ram. daddr2[23:0] data ram address output this 24-bit bus contains the data ram address. addressing is performed on word boundaries. dwe bit function dwe3 write enable for dwdata[31:24] dwe2 write enable for dwdata[23:16] dwe1 write enable for dwdata[15:8] dwe0 write enable for dwdata[7:0] 2-12 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. denable2 word-based data chip enable output the ARM966E-S asserts this output high to indicate the data ram data bus is enabled. drdata2[31:0] data ram read data input this 32-bit bus contains data read from the data ram. dwdata2[31:0] data ram write data output this 32-bit bus provides write data to the data ram. dwe2[3:0] byte based data write enable output the ARM966E-S asserts these outputs high to enable writes to the data ram. 2.5 dma signals dmaa[25:0] dma address input this 26-bit address contains the byte address for dma transfers. tie all unused address bits low. dmad[31:0] dma write data input this 32-bit bus contains the dma write data to the data ram. dmaenable dma port enable input dmaenable must be asserted high for a dma transfer to proceed. asserting dmaenable low can be used to save power when the dma interface is not being used. tie dmaenable low if the dma interface is not used in the implementation. dwe2 bit function dwe3 write enable for dwdata[31:24] dwe2 write enable for dwdata[23:16] dwe1 write enable for dwdata[15:8] dwe0 write enable for dwdata[7:0] dma signals 2-13 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. dmamas[1:0] dma memory access size input dmamas[1:0] encodes the size of dma writes. dma reads are always one word wide. dmanreq dma request input dmanreq is an active-low dma transfer request. tie this input high if the dma interface is not used. dmanrw dma write not read input dmanrw is the dma read/write signal. dmardata[31:0] dma read data output this 32-bit bus contains dma data read from the data ram. dmaready dma ready output dmaready is asserted high when the ARM966E-S is stalled due to a dma wait request. dmaready must be sampled high before a dma transfer to/from a single-port data ram can take place. dmawait dma wait request input dmawait is asserted high to stall the ARM966E-S before proceeding with a dma transfer to/from a single-port data ram implementation. a high on dmaready indicates when the ARM966E-S is stalled. only use this signal for single-port data ram implementations. tie it low for dual-port data ram implementations. dmamas[1:0] memory access size 00 byte 01 halfword 10 word 11 reserved dmanrw function 0 read 1 write 2-14 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 2.6 debug signals commrx communications channel receive output when high, this signal indicates that the comms channel receive buffer has data that the arm9e-s processor core can read. commtx communications channel transmit output when high, this signal indicates the comms channel transmit buffer is empty. dbgack debug acknowledge output when high, dbgack indicates that the arm9e-s processor core is in debug mode. dbgdewpt debug watchpoint input this input can halt the processor for debug purposes. if high at the end of a data memory request cycle, this input causes the arm9e-s processor core to enter the debug state. dbgen debug enable input a low on this input disables the debug features of the ARM966E-S. tie this input low when debugging is not required. dbgext[1:0] breakpoint/watchpoint external condition input these inputs to the embeddedice logic make breakpoints/watchpoints dependent on external conditions. dbgiebkpt processor execution breakpoint input when this input is asserted, processor execution is halted for debug purposes. if dbgiebkpt is high at the end of an instruction fetch, the arm9e-s processor core enters the debug state if that instruction reaches the execute stage of the processor s pipeline. dbginstrexec instruction executed output when this output is asserted high, the instruction in the execute stage of the processor s pipeline was executed. debug signals 2-15 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. dbgir[3:0] tap controller instruction register output these outputs re?ct the current instruction loaded into the tap controller instruction register. they change when the tap state machine is in the update_ir state on the rising edge of clk when dbgtcken is asserted. dbgntdoen dbgtdo 3-state enable output when low, this signal indicates there is serial data on the dbgtdo output. dbgntdoen can be used as the output enable on a packaged part s dbgtdo pin. dbgntrst not test reset input this active-low input is the internally synchronized reset signal for the embeddedice internal state. dbgrng[1:0] watchpoint register match output these outputs indicate that the corresponding embeddedice watchpoint register has matched the conditions currently present on the address, data, and control buses. these signals are independent of the state of the watchpoint s enable control bit. dbgrqi internal debug request output this signal is the debug request signal presented to the processor core s debug logic. it is the anding of edbgrq as presented to the ARM966E-S and bit 1 of the debug control register. dbgscreg[4:0] scan chain register output these outputs re?ct the id number of the scan chain currently selected by the tap controller. they change when the tap state machine is in the update_dp state on the rising edge of clk when dbgtcken is asserted. dbgsdin boundary scan serial input data output this output contains the serial data for an external scan chain. dbgsdout boundary scan serial output data input dbgsdout is the serial data input from an external scan chain. when an external scan chain is not implemented, tie this signal low. 2-16 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. dbgtapsm[3:0] tap controller state machine output this bus re?cts the current state of the tap controller state machine. the tap controller follows the ieee 1149.1 test access port protocol. dbgtcken test clock enable input this input is the synchronous enable for the test clock. dbgtdi test data in input dbgtdi contains data input from the boundary scan logic. dbgtdo test data out output the ARM966E-S outputs test data on dbgtdo from its boundary scan logic. dbgtms test mode select input dbgtms is the jtag test mode select signal. the test mode follows the ieee 1149.1 test access port protocol. edbgrq external debug request input an external debugger asserts this signal to force the processor to enter the debug state. 2.7 etm interface signals these signals are part of the trace module interface. all etm outputs are registered from the corresponding core internal signals. etmbigend endian mode output when this signal is high, the endian mode is big endian; when etmbigend is low, the mode is little endian. etm interface signals 2-17 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. etmchsd[1:0] etm coprocessor handshake decode output these outputs are the handshake signals from the decode stage of the coprocessor s pipeline follower. etmchse[1:0] etm coprocessor handshake execute output these outputs are the handshake signals from the execute stage of the coprocessor s pipeline follower. etmda[31:0] etm data address output this 32-bit bus contains the etm data address. etmdabort etm data abort output the ARM966E-S asserts this signal to indicate a data abort to the arm9e-s processor core. etmdbgack etm debug mode indication output when high, this signal indicates that the processor is in the debug state. etmdmas[1:0]etm data size indicator output these signals indicate the data size of the etm. they become valid in the same cycle as the data address bus: etmchsd[1:0] encoding 10 absent 00 wait 01 go 11 last etmchse[1:0] encoding 10 absent 00 wait 01 go 11 last dmas[1:0] transfer size 00 byte 01 halfword 10 word 11 reserved 2-18 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. etmdmore etm sequential data indication output the etmdmore signal is active during load and store multiple instructions and only goes high when etmdnmreq is low. this signal effectively gives the same information as etmdseq, but a cycle ahead. this information is provided to allow external logic more time to decode sequential cycles. etmdnmreq etm data memory request output this signal is asserted high when the ARM966E-S is making a request to the etm data memory. etmdnrw etm data r/w output if this signal is low at the end of the cycle, then any data memory access in the following cycle is a read. if this signal is high, then the access is a write. etmdseq etm sequential data indication output if this signal is high at the end of the cycle, then any data memory access in the following cycle is sequential from the last data memory access. etmen etm enable input when this signal is high, the etm is enabled and the ARM966E-S interface signals are driven out of this module, pipelined by one clock stage. etmhivecs exception vector location output when this output is low, the ARM966E-S exception vectors start at address 0x0000.0000. when this signal is high, the ARM966E-S exception vectors start at address 0xffff.0000. this output is a static con?uration signal. etmia[31:1] etm instruction address bus output this 31-bit bus contains the address for the etm. etmid31to25[31:25] bits [31:25] of instruction data output these outputs re?ct the status of bits [31:25] of the instruction data read by the ARM966E-S. etmid15to11[15:11] bits [15:11] of instruction data output these outputs re?ct the status of bits [15:11] of the instruction data read by the ARM966E-S. etm interface signals 2-19 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. etminmreq etm instruction memory request output the ARM966E-S drives this output low to indicate that an instruction fetch will take place. etminstrexec etm instruction execute indicator output the ARM966E-S asserts this output high to indicate that the instruction in the execute stage of the processor pipeline has been executed. etmiseq etm sequential instruction output the etmiseq signal indicates whether the fetch is sequential (high) or nonsequential (low) to the previous access. etmitbit etm thumb indication output when this signal is low, the processor is in arm state and it fetches 32-bit instructions. when etmitbit is high, the processor is in thumb state and it fetches 16-bit instructions. etmlatecancel etm coprocessor late cancel indicator output if this output is high during the ?st memory cycle of a coprocessor instruction, then the coprocessor should cancel the instruction without changing any internal state. this signal is only asserted in cycles where the previous instruction accessed memory and a data abort occurred. etmnwait etm clock stall output driving this output low stalls the etm. etmpass etm coprocessor instruction execute indicator output a high on this signal indicates that there is a coprocessor instruction in the execute stage of the pipeline, which should be executed. etmrdata[31:0] etm read data output this 32-bit bus contains etm read data. etmrngout[1:0] etm watchpoint register match output this output indicates that corresponding embeddedice watchpoint register has matched the conditions currently 2-20 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. present on the address, data, and control buses. this signal is independent of the state of the watchpoint s enable control bit. etmwdata[31:0] etm write data output this 32-bit bus contains etm write data. etminstrvalid etm instruction valid output the ARM966E-S asserts this output high to indicate the current instruction is valid for the etm. etmprocid[31:0] etm process id output this 32-bit output contains the process id for the etm. etmprocidwr] etm process id write output this output is asserted when etmprocid is written. fifofull etm fifo full input this input is asserted when the etm fifo is full. tie this signal low if an etm is not used. tapid[31:0] boundary scan id code input this bus speci?s the id code value shifted out on dbgtdo when the idcode instruction enters the tap controller. 2.8 miscellaneous signals bigendout big endian output when this output is high, the ARM966E-S is in big-endian mode (byte 0 is the most-signi?ant bit). when this output is low, the ARM966E-S is in little-endian mode. this output is a static con?uration signal. it must remain at one value from reset or be changed using a carefully constructed code sequence to avoid software problems. clk system clock input clk is the ARM966E-S system clock. clk can be stretched in either state (held high or low). initialization control signals 2-21 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. hclken hclk enable input hclken is used in conjunction with clk to effectively run the ARM966E-S at a higher frequency than the ahb system bus. hclken is high for a single clk period and signi?s the rising edge of the ahb clock, hclk. all ahb outputs transition on the clk rising edge in which hclken is asserted. nfiq not fast interrupt input this active-low input is the arm fast interrupt request. the ARM966E-S supports synchronous interrupts only. nirq not interrupt request input this active-low input is the arm interrupt request. the ARM966E-S supports synchronous interrupts only. 2.9 initialization control signals initram ram enable con?uration input when initram is high, the instruction and data rams are enabled at the end of reset. when it is low, the instruction and data rams are disabled coming out of reset. this input is a static con?uration signal. its value is sampled at reset only. vinithi high vectors con?uration input when vinithi is low at reset, the exception vectors start at address 0x0000.0000. when vinithi is high, the exception vectors start at 0xffff.0000. this signal is a static con?uration signal. its value is sampled at reset only. 2.10 atpg scan control signals scanen scan enable input the ARM966E-S asserts this input high to enable data scanning through the scan chain. 2-22 signal descriptions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. si scan chain in input si is the input for the serial scan chain. there can be multiple si/so scan pairs. so scan chain out output so is the output for the serial scan chain. there can be multiple si/so scan pairs. ARM966E-S microprocessor core technical manual 3-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 3 programmer s model this chapter describes the programmer s model of the ARM966E-S microprocessor core. this chapter contains the following sections: ? section 3.1, ?bout the programmer s model ? section 3.2, ?ata abort model ? section 3.3, ?ata types ? section 3.4, ?rocessor modes ? section 3.5, ?p15 instruction format ? section 3.6, ?emory map ? section 3.7, ?egisters 3.1 about the programmer s model the programmer s model for the ARM966E-S consists of the arm9e-s programmer s model with some additions. the added features control both the operation of the ARM966E-S internal coprocessors and any coprocessor connected to the external coprocessor interface. there are two internal coprocessors within the ARM966E-S: ? coprocessor 14 (cp14) within the arm9e-s core allows software access to the debug communications channel ? coprocessor 15 (cp15) allows con?uration of the tightly coupled sram and write buffer and other ARM966E-S system options, such as big- or little-endian operation. the cp14 registers are accessible with mcr and mrc instructions. these registers are described in section 10.9, ?he debug communications channel. 3-2 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the cp15 registers are accessible with mcr and mrc instruction. these registers are de?ed in section 3.7.2, ?p15 registers. any coprocessors and their registers that are attached to the external coprocessor interface are accessible with the appropriate coprocessor instructions. 3.2 data abort model the ARM966E-S implements the base restored data abort model , which differs from the base updated data abort model implemented by the arm7tdmi. the difference in the data abort model affects only a very small section of operating system code, the data abort handler. it does not affect user code. with the base restored data abort model, when a data abort exception occurs during the execution of a memory access instruction, the processor hardware always restores the base register to the value the register contained before the instruction was executed. this step removes the requirement for the data abort handler to unwind any base register update that might have been speci?d by the aborted instruction. the base restored data abort model signi?antly simpli?s the software data abort handler. 3.3 data types the ARM966E-S supports the data types listed in table 3.1. table 3.1 supported data types data type size byte 8 bits halfword 16 bits (halfwords must be aligned to two-byte boundaries) word 32 bits (words must be aligned to four-byte boundaries) processor modes 3-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. arm instructions are exactly one word (32 bits) and are aligned on a four-byte boundary. thumb instructions are exactly one halfword (16 bits) and are aligned on a two-byte boundary. all data operations (for example, add) are performed on word quantities. load and store operations can transfer bytes, halfwords, and words to and from memory, automatically zero-extending or sign-extending bytes or halfwords as they are loaded. signed operands are in two s complement format. 3.4 processor modes the ARM966E-S supports seven processor modes. these modes are summarized in table 3.2. mode changes occur either through software control or as a result of external interrupts or exception processing. most application programs execute in user mode. the other modes, known as privileged modes , are entered to service interrupts or exceptions or to access protected resources. table 3.2 arm9e-s processor modes processor mode description user (usr) normal program execution mode fiq (fiq) high-speed data transfer or channel process irq (irq) general-purpose interrupt handling supervisor (svc) protected mode for the operating system abort (abt) virtual memory and/or memory protection implementation unde?ed (und) software emulation of hardware coprocessors system (sys) privileged operating system tasks (architecture version 4 only) 3-4 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 3.5 cp15 instruction format system control coprocessor 15 (cp15) controls the operation and con?uration of the instruction ram, data ram, and write buffer. this coprocessor is backward-compatible with the arm7. all unused and reserved bits should be programmed to zeros. to read and write the con?uration registers, use the mrc and mcr instructions, respectively. these operations are only allowed in nonuser modes; an unde?ed instruction trap is taken if accesses are attempted in user mode. figure 3.1 shows the ?lds that make up the instruction format. figure 3.1 coprocessor instruction format table 3.3 de?es the ?lds within the coprocessor instruction format. 31 28 27 24 23 21 20 19 16 15 12 11 8 7 5 4 3 0 cond 1110 opcode_1 n crn rd 1111 opcode_2 1 crm table 3.3 instruction format field descriptions field name function cond arm condition code opcode_1 arm opcode 1. opcode_1 is zero for all cp15 instructions. n load/store bit 0 = mrc (cp15 register read) 1 = mcr (cp15 register write) crn cp15 source/destination register. this ?ld determines which con?uration register is being accessed. rd arm cpu register 1111 coprocessor number (p15) opcode_2 arm opcode 2 crm cp15 operand register memory map 3-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. one example of an mrc register read instruction using the above format is mrc p15, 0, rd, c0, c0, 0 , where p15 = 1111, 0 = opcode_1, rd = arm cpu register, c0 = crn, c0 = crm, and 0 = opcode_2. 3.6 memory map figure 3.2 shows the memory map for the ARM966E-S. figure 3.2 ARM966E-S memory map 3.7 registers this section describes the cpu and cp15 register sets. ahb unbuffered ahb buffered ahb unbuffered ahb buffered data memory instruction memory 0xffff.ffff 0xf000.0000 0xefff.ffff 0x3000.0000 0x2fff.ffff 0x2000.0000 0x1fff.ffff 0x1000.0000 0x0fff.ffff 0x0800.0000 0x07ff.ffff 0x0f00.0000 0x03ff.ffff 0x0000.0000 256 mbytes 256 mbytes 256 mbytes 128 mbytes 64 mbytes 64 mbytes 3-6 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 3.7.1 cpu registers the processor has a total of 37 registers: ? 30 32-bit-wide general-purpose registers ? 6 status registers ? 1 program counter the registers are arranged in partially overlapping banks. each of the seven processor modes has a different register bank. at any one time, 15 general-purpose registers (r0 through r14), one or two status registers, and the program counter are visible. the current processor mode determines which general-purpose registers and status registers are currently visible. figure 3.3 shows the register bank organization. the banked registers are shaded in the ?ure. figure 3.3 cpu register organization mode user/system supervisor abort unde?ed interrupt fast interrupt r0 r0 r0 r0 r0 r0 r1 r1 r1 r1 r1 r1 r2 r2 r2 r2 r2 r2 r3 r3 r3 r3 r3 r3 r4 r4 r4 r4 r4 r4 r5 r5 r5 r5 r5 r5 r6 r6 r6 r6 r6 r6 r7 r7 r7 r7 r7 r7 r8 r8 r8 r8 r8 r8_fiq r9 r9 r9 r9 r9 r9_fiq r10 r10 r10 r10 r10 r10_fiq r11 r11 r11 r11 r11 r11_fiq r12 r12 r12 r12 r12 r12_fiq r13 r13_svc r13_abort r13_undef r13_irq r13_fiq r14 r14_svc r14_abort r14_undef r14_irq r14_fiq pc pc pc pc pc pc cpsr cpsr cpsr cpsr cpsr cpsr spsr_svc spsr_abort spsr_undef spsr_irq spsr_fiq registers 3-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 3.7.1.1 stack pointer (sp) register 13 is the stack pointer. it is banked across all modes to provide a private stack pointer for each mode (except for system mode which shares the user-mode r13). 3.7.1.2 link register (lr) register 14 is the link register. it holds the address of the next instruction after a branch with link (bl) instruction, which is the instruction used to make subroutine calls. all other times, r14 can be used as a general-purpose register. 3.7.1.3 program counter (pc) register 15 is the program counter. it is used in most instructions as a pointer to the instruction that is two instructions after the instruction being executed. because all arm instructions are one word long and are always aligned on word boundaries, the bottom two bits of the pc are always zeros. when the pc is read, bits [1:0] are zeros and bits [31:2] contain the pc. when the pc is written, bits [1:0] are ignored and bits [31:2] are written to the pc. depending on how the pc is used, its value is either the address of the instruction plus 8 or is unpredictable. 3.7.1.4 banked registers in fiq mode registers r8 through r14 in fiq mode are banked. they provide very fast interrupt processing without the need for preserving register contents by storing them to memory. values are preserved across interrupt calls so that register contents do not need to be restored from memory. 3.7.1.5 current program and saved program status registers (cpsr and spsr) the cpsr is accessible in all processor modes. it contains condition code ?gs, interrupt enable ?gs, and the current mode. each privileged mode (except system mode) has an spsr, which preserves the value of the cpsr when an exception occurs. figure 3.4 shows the format of the cpsr and spsr. 3-8 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 3.4 program status registers (cpsr and spsr) format the n (negative), z (zero), c (carry), v (over?w), and s (sticky) bits are the condition code ?gs. the condition code ?gs in the cpsr can be changed as a result of arithmetic and logical operations in the processor and can be tested by all instructions to determine whether the instruction is to be executed. the s bit supports the arm9e instruction extensions. it is set whenever either a saturation occurs during a qadd, qdadd, qsub, or qdsub instruction or when the result of an smlaxx or smlawx instruction over?ws 32 bits. you must use an mrs instruction to observe the contents of the s ?g. the s ?g is sticky. once it is set, then no subsequent instruction will reset it apart from an msr instruction writing to the cpsr. refer to appendix a for descriptions of the arm9e instruction extensions. bits [26:8] are reserved. they read as zeros and may only be written with the same value read from the same ?ld as the processor. bits [7:0] are the control bits. they change when an exception arises and can be altered by software only when the processor is in a privileged mode. the i bit disables irq interrupts when it is set. when set, the f bit disables fiq interrupts. when the t ?g is zero, it indicates arm execution; when it is set, it indicates thumb execution. the mode bits, m[4:0], determine the mode in which the processor operates. table 3.4 shows the encoding of these bits. values not shown in the table are invalid; their results are unpredictable. 31 30 29 28 27 26 8 7 6 5 4 3 2 1 0 nzcvs res i f t m4m3m2m1m0 registers 3-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. user mode and system mode do not have an spsr, as these modes are not entered on any exception, so a register to preserve the cpsr is not required. in user or system mode, any reads to the spsr read an unpredictable value, and any writes to the spsr are ignored. 3.7.2 cp15 registers use the mcr and mrc instructions to access the con?uration registers; the processor must be in supervisor (privileged) mode. never access an invalid crn register because neither the access nor an unde?ed instruction trap occurs. an access to a crn register in user mode causes the unde?ed instruction trap to be taken. table 3.4 mode bits m[4:0] mode accessible registers 0b10000 user pc, r0 through r14, cpsr 0b10001 fiq pc, r0 through r7, r8_? through r14_?, cpsr, spsr_? 0b10010 irq pc, r0 through r12, r13_irq, r14_irq, cpsr, spsr_irq 0b10011 svc pc, r0 through r12, r13_svc, r14_svc, cpsr, spsr_svc 0b10111 abort pc, r0 through r12, r13_abt, r14_abt, cpsr, spsr_abt 0b11011 undef pc, r0 through r12, r13_und, r14_und, cpsr, spsr_und 0b11111 system pc, r0 through r14, cpsr table 3.5 cp15 register map register function 0 id code 1 control 2? reserved 7 core control 8?2 reserved 3-10 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 3.7.2.1 id code register (0) register 0 is a read-only register that lists the core identi?r. accessing register 0 with the mrc p15, 0, rd, c0, c0, 0 instruction returns the id code. id code register the id code register is a read-only identity register that returns the lsi logic code for this core. this code is made up of four ?lds. implementor [31:24] this ?ld contains an eight-bit value unique to lsi logic corporation. its value is 0x41. architecture version [23:16] this ?ld speci?s the arm9e-s architecture. its value is 0x05 (version 5t). lsi logic core id [15:4] this ?ld contains a 12-bit value that uniquely identi?s this core. its value is 0x966. revision [3:0] this four-bit ?ld indicates the revision number. its value is 0x0. 3.7.2.2 control register (1) the control register is a read/write register that contains the control bits. the reserved bits denoted as sbz should be written with zeros; the reserved bits denoted as sbo should be written with ones. all bits are 13 trace process identi?r 14 reserved (unde?ed instruction) 15 test table 3.5 cp15 register map (cont.) register function 31 24 23 16 15 4 3 0 implementor architecture version lsi logic core id revision registers 3-11 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. cleared to zero on reset unless stated otherwise. the reserved bits have an unpredictable value when read. res (sbz) reserved [31:16], 14, [11:8], [1:0] these bits are reserved and must be written as zeros. tbit con?ure disable loading tbit 15 this bit controls the behavior of load pc instructions. when tbit is cleared, a load to the pc uses bit 0 of the loaded data to control the entry into the thumb state. when tbit is set, this behavior is disabled. at reset, this bit is cleared. v alternate vector select 13 this read-only bit controls the base address used for the exception vectors. when v is cleared, the base address for the exception vectors is 0x0000.0000. when v is set, the base address for the exception vectors is 0xffff.0000. at reset, this bit takes on the value of the vinithi pin. i instruction memory enable bit 12 when this bit is set, all accesses to the instruction memory space will access the instruction ram. when this bit is cleared, all accesses to the instruction memory space will access the ahb. at reset, this bit takes on the value of the initram pin. e big/little endian bit 7 this bit determines the byte-ordering convention. it is cleared during reset. res (sbo) reserved [6:4] these bits are reserved and must be written as ones. 31 16 15 14 13 12 11 8 7 6 4 3 2 1 0 res (sbz) tbit res (sbz) vi res (sbz) e res (sbo) w b d res (sbz) e endian 0 little endian 1 big endian 3-12 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. wb write buffer enable 3 this bit determines whether the write buffer is enabled or not. at reset, the write buffer is disabled. d data memory enable bit 2 this bit determines whether data accesses will access the data ram or the ahb. at reset, this bit takes on the value of the initram pin. 3.7.2.3 core control register (7) the core control register is a write-only register. writes to this register can drain the write buffer, or cause a wait for interrupts. a read of this register returns an unspeci?d value. table 3.6 shows the valid write instructions to this register with their corresponding functions. drain write buffer coprocessor 15 can stall instruction execution until the write buffer is emptied. this operation is useful in real-time applications where the processor needs to be sure that a write to a peripheral has completed before program execution continues. an example is where a peripheral in a bufferable region is the source of an interrupt. once the interrupt has been serviced, the request must be removed before interrupts can be re-enabled. the processor can be sure of the removal if a drain write-buffer operation separates the store to the peripheral and the enable interrupt functions. wb description 0 write buffer disabled 1 write buffer enabled d description 0 data ram accessed 1 ahb accessed table 3.6 core control instructions arm instruction data function mcr p15, rd, c7, c10, 4 sbz drain write buffer mcr p15, rd, c7, c0, 4 sbz wait for interrupt mcr p15, rd, c15, c8, 2 sbz wait for interrupt (strongarm backward compatibility) registers 3-13 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. invoking the drain write buffer instruction stalls the processor core until any outstanding accesses in the write buffer have been completed (all data has been written to memory). wait for interrupt the wait for interrupt instructions allow the ARM966E-S to enter a low power standby mode. when the operation is invoked, the internal system clock enable signal (clken) is negated until either an interrupt or a debug request occurs. this function is invoked by a write to register 7 using the mcr p15, rd, c7, c0, 4 instruction. the mcr p15, 0, rd, c15, c8, 2 instruction is provided to support older software. when the wait for interrupt instruction is executed, the processor is stalled until nfiq, nirq, or edbgrq is asserted. also if the debugger sets the debug request bit in the embeddedice control register, then the wait-for-interrupt condition terminates. when either nfiq or nirq is asserted, the processor ?akes up regardless of whether the interrupts are enabled or disabled (independent of the i and f bits in the processor s cpsr). the debug-related awakening only occurs if dbgen is set (when debug is enabled). if interrupts are enabled, the ARM966E-S is guaranteed to take the interrupt before executing the instruction after the wait for interrupt. if interrupts are disabled, the ARM966E-S restarts execution of the instruction following the wait for interrupt. if a debug request is used to wake up the system, then the processor enters the debug state before executing any further instructions. wait for interrupt does not prevent the write buffer from emptying. 3.7.2.4 trace process identi?r (13) this register allows the real-time trace tools to identify the currently executing process in multitasking environments. the contents of this register are replicated on the etmprocid[31:0] outputs of the ARM966E-S. the etmprocidwr signal is asserted high for a single clock cycle whenever a write to this register occurs. table 3.7 shows the trace process identi?r for reads and writes. 3-14 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 3.7.2.5 cp15 test (15) lsi logic does not implement the arm test register set. use the lsi logic recommended tool to implement rambist in your design. writes to the arm test registers have no effect. reads from the test registers result in default values of 0. the cp15 rambist control registers provide control of and access to the instruction and data rams so that memory failures can be isolated or forced. table 3.8 shows the register map for cp15 register 15. table 3.7 register 13, trace process identi?r register read write trace process identi?r mrc p15, 0, rd, c13, c1, 1 mcr p15, 0, rd, c13, c1, 1 table 3.8 cp15 rambist register map register register reads register writes 1 bist control register mrc p15, 1, rd, c15, c0, 1 bist control register mcr p15, 1, rd, c15, c0, 1 2 instruction bist fail address register mrc p15, 1, rd, c15, c0, 2 instruction bist start/pause address register mcr p15, 1, rd, c15, c0, 2 3 instruction bist fail/pause read data register mrc p15, 1, rd, c15, c0, 3 instruction bist test/pause write data register mcr p15, 1, rd, c15, c0, 3 4? reserved (unde?ed instruction) reserved (unde?ed instruction) 6 data bist fail address register mrc p15, 1, rd, c15, c0, 6 data bist start/pause address register mcr p15, 1, rd, c15, c0, 6 7 data bist fail/pause data register mrc p15, 1, rd, c15, c0, 7 data bist test/pause data register mcr p15, 1, rd, c15, c0, 7 registers 3-15 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. bist control register this register controls the operation of the memory bist. when written, this register controls the instruction and data memory bist wrappers. ibistsize instruction bist size w [31:21] reserved r [31:21] this write-only ?ld de?es the size of the instruction memory as n . ibistsize in bytes is 4 x 2 n . icom ibist complete r 20 reserved w 20 a one on this read-only bit indicates the instruction bist run has completed. this bit is hardcoded to 0x1, bist complete. ifail ibist fail r 19 reserved w 19 a one on this read-only ?ld indicates the instruction bist detected a memory failure. this bit is hardcoded to 0x0. ien ibist enable r/w 18 setting this bit enables the ibist controller to drive the instruction memory address, data, write enable, and chip select signals. this bit must be set before issuing an ibistrun. it must remain set for the duration of the ibist test. ipause ibist pause r/w 17 setting this bit pauses the instruction bist operation. this facility is useful for inserting errors and isolating failures. irun ibistrunning r 16 ibistrun w 16 when reading this bit, a one indicates the instruction bist is running. if ipause is set, then ibistrunning is deasserted when bist execution is paused. this bit is hardcoded to 0x0, bist not running. 31 21 20 19 18 17 16 15 5 4 3 2 1 0 ibistsize i com i fail i en i pause i run dbistsize d com d fail d en d pause d run 3-16 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. dbistsize data bist size w [15:5] reserved r [15:5] this write-only ?ld de?es the size of the data memory as n . dbistsize in bytes is 4 x 2 n . dcom dbist complete r 4 reserved w 4 a one on this read-only bit indicates the data bist run has completed. this bit is hardcoded to 0x1, bist complete. dfail dbist fail r 3 reserved w 3 a one on this read-only ?ld indicates the data bist detected a memory failure. this bit is hardcoded to 0x0. den dbist enable r/w 2 setting this bit enables the dbist controller to drive the data memory address, data, write enable, and chip select signals. this bit must be set before issuing a dbistrun. it must remain set for the duration of the dbist test. dpause dbist pause r/w 1 setting this bit pauses the data bist operation. this facility is useful for inserting errors and isolating failures. drun dbistrunning r 0 dbistrun w 0 when reading this bit, a one indicates the data bist is running. if dpause is set, then dbistrunning is deasserted when bist execution is paused. this bit is hardcoded to 0x0, bist not running. instruction bist start/pause address register the function of this write-only register depends on the setting of the ipause bit in the cp15 bist control register. when the instruction bist pause bit is cleared, a write to this register determines the instruction bist start address. bist testing is executed on instruction memory from the ibist start address to an address that is a function of the ibist size with respect to the start address. normally 31 26 25 0 reserved ibist start address/ibist pause address registers 3-17 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. this register is cleared to allow testing of the full instruction memory. however, it can be set to a nonzero value to limit testing to only a portion of instruction memory. when the instruction bist pause bit is set, a write to this register sets the instruction pause address. when bist testing is paused, the pause address is held at the instruction memory ram address input. cp15 instruction bist test/pause write data register the function of this write-only register depends on the setting of the ipause bit in the cp15 bist control register. when the instruction bist pause bit is cleared, a write to this register sets the instruction bist data pattern (ibisttestdata). the bist algorithm uses ibisttestdata and its inverse pattern for instruction memory bist testing. when the instruction bist pause bit is set and bist operation is paused, data written to this register is placed in the instruction memory at the ibist pause address. cp15 instruction bist fail address register this read-only register contains the address of the ?st detected instruction memory failure. this register is valid when the instruction ram bist fail bit is set in the cp15 bist control register. because arm bist was not implemented, this register is hardcoded to 0x00000000. cp15 instruction bist fail/pause read data register the function of this read-only register depends on the setting of the ipause bit in the cp15 bist control register. because arm bist was not implemented, this register has been hardcoded to 0x00000000. 31 0 ibist test data/ibist pause write data 31 26 25 0 reserved ibist fail address 3-18 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. cp15 data bist start/pause address register the function of this write-only register depends on the setting of the dpause bit in the cp15 bist control register. when the data bist pause bit is cleared, a write to this register determines the data bist start address. bist testing is executed on data memory from dbist start address to a function of the dbist size with respect to the start address. normally, this register is cleared to allow testing of the full data memory. however, it can be set to a nonzero value to limit testing to only a portion of data memory. when the data bist pause bit is set, a write to this register sets the data pause address. when bist testing is paused, the pause address is held at the data memory ram address inputs. cp15 data bist test/pause write data register the function of this write-only register depends on the setting of the dpause bit in the cp15 bist control register. when the data bist pause bit is cleared, a write to this register sets the data bist data pattern (dbisttestdata). the bist algorithm uses dbisttestdata and its inverse pattern for data memory bist testing. when the data bist pause bit is set and bist operation is paused, data written to this register is placed in the data memory at the dbist pause address. cp15 data bist fail address register this read-only register contains the address of the ?st detected data memory failure. this register is valid when the data ram bist fail bit is set in the cp15 bist control register. 31 0 ibist fail data/ibist pause read data 31 26 25 0 reserved dbist start address/dbist pause address 31 0 dbist test data/dbist pause write data registers 3-19 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. because arm bist is not implemented, this register is hardcoded to 0x00000000. cp15 data bist fail/pause read data register the function of this read-only register depends on the setting of the dpause bit in the cp15 bist control register. because arm bist is not implemented, this register is hardcoded to 0x00000000. 31 26 25 0 reserved dbist fail address 31 0 dbist fail data/dbist pause read data 3-20 programmer s model rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. ARM966E-S microprocessor core technical manual 4-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 4 exception processing this section describes all events that cause exceptions, de?es the types of exceptions, and explains how they are resolved. ? section 4.1, ?verview ? section 4.2, ?xception flow ? section 4.3, ?xception descriptions 4.1 overview internal and external sources generate exceptions, which cause the processor to handle an exceptional event, such as a hardware interrupt or an attempt to execute an unde?ed instruction. the processor state just before handling the exception must be preserved so that the original program can be resumed when the exception routine has completed. more than one exception may arise at the same time. the ARM966E-S supports seven types of exceptions; each type of exception has a privileged processor mode. table 4.1 shows the types of exceptions with their corresponding processor mode that processes that exception. when an exception occurs, execution is forced to an exception vector location. 4-2 exception processing rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. table 4.2 lists exceptions from highest to lowest priority. while more than one exception can occur for a single instruction, only the exception with the highest priority is reported. 4.2 exception flow when an exception occurs, some of the standard registers are replaced with registers speci? to the exception mode. all exceptions have banked table 4.1 exception processing modes exception type mode vector address reset svc 0x0000.0000 unde?ed instructions undef 0x0000.0004 software interrupt (swi) svc 0x0000.0008 prefetch abort (instruction fetch memory abort) abort 0x0000.000c data abort (data access memory abort) abort 0x0000.0010 irq (interrupt) irq 0x0000.0018 fiq (fast interrupt) fiq 0x0000.001c table 4.2 exception priority order exception priority reset 1 (highest) data abort 2 fiq 3 irq 4 prefetch abort 5 bkpt, unde?ed instruction, swi 6 (lowest) exception flow 4-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. registers for r14 and r13. one interrupt mode has more banked registers for fast interrupt processing. after an exception, r14 holds the return address for exception processing. this address is used to return after the exception is processed and to address the instruction that caused the exception. r13 is banked across exception modes to provide each exception handler with a private stack pointer (sp). the fast interrupt mode also banks registers 8 through 12, so that interrupt processing can begin without the need to save or restore these registers. the system mode does not have any banked registers; it uses the user-mode registers. system mode is used to run normal (nonexception) tasks that require a privileged processor mode. all other processor states are held in the status registers: cpsr and spsr. the current operating processor status is in the current program status register (cpsr). the cpsr holds four condition code ?gs (n, z, c, and v), two interrupt disable bits (irq and fiq), and ?e bits that encode the current processor mode. all exception modes except for user and system have a saved program status register (spsr), which holds the cpsr of the task immediately before the exception occurred. both the cpsr and spsr are accessed with special instructions. when an exception occurs, the arm9e-s processor core halts execution after the current instruction and begins execution at the ?ed address in low memory, pointed at by the exception vectors. each exception has a separate vector location. memory aborts have two vector locations to distinguish between data and instruction accesses. at initialization, the operating system installs a handler on every exception. privileged operating system tasks are normally run in system mode to allow exceptions to occur within the operating system without state loss. exceptions overwrite their r14 when an exception occurs, and system mode is the only privileged mode that cannot be entered by an exception. 4-4 exception processing rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 4.3 exception descriptions this section provides detailed descriptions of the seven exception types. it describes the cause of each exception and describes how each exception is processed. 4.3.1 reset exception cause the reset exception occurs when the processor reset signal is asserted. processing the arm9e-s processor core immediately stops execution of the current instruction. when the reset is deasserted, the following actions occur: ? r14_svc is loaded with an unpredictable value ? spsr_svc is loaded with the contents of cpsr ? cpsr[5:0] are set to 0b010011 (supervisor mode) ? cpsr6 is set to one (fast interrupts are disabled) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the reset vector (0x0) 4.3.2 unde?ed instruction execution cause when the arm9e-s executes a coprocessor instruction, it waits for any external coprocessor to acknowledge that it can execute the instruction. if no coprocessor responds, an unde?ed instruction exception occurs. if an attempt is made to execute an instruction that is unde?ed, an unde?ed instruction exception occurs. this exception can be used for software emulation of a coprocessor in a system that does not have the physical coprocessor or for general-purpose instruction set extension by software emulation. processing when an unde?ed instruction exception occurs, the following actions occur: ? r14_und is loaded with the address of the unde?ed instruction + 4 ? spsr_und is loaded with the contents of cpsr exception descriptions 4-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. ? cpsr[5:0] are set to 0b011011 (unde?ed mode) ? cpsr6 remains unchanged (fast interrupt status is unchanged) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the unde?ed instruction exception vector (0x4) to return after emulating the unde?ed instruction, use movs pc, r14 . this instruction restores the pc (from r14_und) and cpsr (from spsr_und) and returns to the instruction following the unde?ed instruction. 4.3.3 software interrupt exception cause the software interrupt instruction (swi) causes a software interrupt exception. the arm9e-s processor core enters supervisor mode to request a particular supervisor (operating system) function. processing when an swi is executed, the following actions occur: ? r14_svc is loaded with the address of the swi instruction + 4 ? spsr_svc is loaded with the contents of cpsr ? cpsr[5:0] are set to 0b010011 (supervisor mode) ? cpsr6 remains unchanged (fast interrupt status is unchanged) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the software interrupt exception vector (0x8) to return after performing the swi operation, use movs pc, r14 . this instruction restores the pc (from (r14_svc) and cpsr (from spsr_svc) and returns to the instruction following the swi. 4.3.4 prefetch abort (instruction fetch memory abort) cause the memory system indicates a memory abort. activating an abort in response to an instruction fetch marks the fetched instruction as invalid. an abort takes place if the processor attempts to execute the invalid instruction. if the instruction is not executed (for example, as a result of a branch being taken while it is in the pipeline), no prefetch abort occurs. 4-6 exception processing rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. processing when an attempt is made to execute an aborted instruction, the following actions occur: ? r14_abt is loaded with the address of the aborted instruction + 4 ? spsr_abt is loaded with the contents of cpsr ? cpsr[5:0] are set to 0b010111 (abort mode) ? cpsr6 remains unchanged (fast interrupt status is unchanged) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the prefetch abort exception vector (0xc) to return after ?ing the reason for the abort, use subs pc, r14, # 4. this instruction restores both the pc (from r14_abt) and cpsr (from spsr_abt) and returns to the aborted instruction. 4.3.5 data abort (data access memory abort) cause the memory system indicates a memory abort. activating an abort in response to a data access (load or store) marks the data as invalid. a data abort exception occurs before any subsequent instructions or exceptions have altered the state of the processor core. processing the following actions occur: ? r14_abt is loaded with the address of the aborted instruction + 8 ? spsr_abt is loaded with the contents of cpsr ? cpsr[5:0] are set to 0b010111 (abort mode) ? cpsr6 remains unchanged (fast interrupt status is unchanged) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the data abort exception vector (0x10) to return after ?ing the reason for the abort, use subs pc, r14, #8 . this instruction restores both the pc (from r14_abt) and cpsr (from spsr_abt) and returns to re-execute the aborted instruction. if the aborted instruction does not need to be re-executed, use subs pc, r14, #4 . for memory access instructions that specify writebacks and exception descriptions 4-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. generate data aborts (ldr, ldrh, ldrsh, ldrb, ldrsb, str, strh, strb, ldm, stm, ldc, stc), the ?al value that these instructions leave in the base register is implementation-de?ed. 4.3.6 irq (interrupt request) exception cause the irq exception is generated when the nirq input is asserted. it has a lower priority than the fiq exception and is masked out when an fiq sequence is entered. interrupts are disabled when the i bit in the cpsr is set (note that the i bit can only be changed from a privileged mode). if the i ?g is cleared, the arm9e-s processor core checks for an irq at instruction boundaries. processing when an irq is detected, the following actions occur: ? r14_irq is loaded with the address of the next instruction to be executed + 4 ? spsr_irq is loaded with the contents of cpsr ? cpsr[5:0] are set to 0b010010 (interrupt mode) ? cpsr6 remains unchanged (fast interrupt status is unchanged) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the interrupt request exception vector (0x18) to return after servicing the interrupt, use subs pc, r14, #4 . this instruction restores both the pc (from r14_irq) and cpsr (from spsr_irq) and resumes execution of the interrupted code. 4.3.7 fiq (fast interrupt request) exception cause the fiq exception is generated when the nfiq input is asserted. fiq supports a data transfer or channel process, and has suf?ient private registers to remove the need for register saving in such applications (thus minimizing the overhead of context switching). fast interrupts are disabled when the f bit in the cpsr is set (note that the f bit can only be altered from a privileged mode). if the f ?g is cleared, the arm9e-s processor core checks for an fiq at instruction boundaries. 4-8 exception processing rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. processing when an fiq is detected, the following actions occur: ? r14_? is loaded with the address of the next instruction to be executed + 4 ? spsr_? is loaded with the contents of cpsr ? cpsr[5:0] are set to 0b010001 (fiq mode) ? cpsr6 is set to one (fast interrupt status is disabled) ? cpsr7 is set to one (normal interrupts are disabled) ? the program counter (pc) is loaded with the interrupt request exception vector (0x1c) to return after servicing the interrupt, use subs pc, r14, #4 . this instruction restores both the pc (from r14_?) and cpsr (from spsr_?) and resumes execution of the interrupted code. the fiq vector is intentionally the last vector to allow the fiq exception-handler software to be placed directly at address 0x1c and not require a branch instruction from the vector. ARM966E-S microprocessor core technical manual 5-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 5 ahb interface unit this chapter describes the operation of the advanced high-performance bus (ahb) interface unit. it contains the following sections: ? section 5.1, ?verview ? section 5.2, ?hb interface signals ? section 5.3, ?hb clocking ? section 5.4, ?hb operation ? section 5.5, ?asic transfers ? section 5.6, ?urst operations 5.1 overview the ahb is a high-performance, burst-based bus protocol that complements the lower level amba advanced system bus (asb) and apb protocols. the ahb bus supplies the needed requirements for high-performance/high clock frequency systems. this bus can handle the following: ? burst transfers ? single-cycle bus master handover ? single clock edge operation ? non-3-state implementation the ahb bus protocol is used with a central multiplexer interconnection scheme. from this scheme, all bus masters drive out the address and control signals indicating the transfer they wish to perform. the arbiter determines which master has its address/control signals routed to all of the slaves. a central decoder is also required to control the read data 5-2 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. and response signal multiplexer, which selects the signals from the slave that is involved in the transfer. figure 5.1 shows the structure that is required to implement an ahb design with three masters and four slaves. figure 5.1 multiplexer interconnection 5.2 ahb interface signals this section describes the signals that determine the transfer type and burst type of each ahb transfer. it also describes the control signals that provide additional information on the transfers. slave #1 slave #2 slave #3 slave #4 haddr haddr haddr haddr hwdata hwdata hwdata hwdata master #1 master #2 master #3 haddr haddr haddr hwdata hwdata hwdata address/ decoder arbiter hrdata hrdata hrdata mux mux hrdata hrdata hrdata hrdata control mux write data mux read data mux mux ahb interface signals 5-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 5.2.1 transfer types every transfer is classi?d into one of four different types, as determined by the htrans[1:0] signals. the ?st transfer of any burst is nonsequential; the address is unrelated to the previous transfer. the remaining transfers in a burst are sequential; the address is related to the previous transfer. single transfers on the bus are treated as bursts of one, and thus the transfer type is nonsequential. the idle transfer type is used when a bus master is granted the bus, but does not wish to perform a data transfer. slaves must provide a zero wait state okay response to idle transfers. the busy transfer type allows bus masters to insert idle cycles in the middle of a burst of transfers. this transfer type indicates that the bus master is continuing with a burst, but the next transfer cannot take place immediately. when a master uses the busy transfer type, the address and control signals must re?ct the next transfer in the burst. the master must always perform this transfer and cannot cancel it at a later point in time. slaves must provide a zero wait state okay response in the same way that they respond to idle transfers. table 5.1 transfer type encoding htrans[1:0] transfer type description 00 idle idle transfer is used when a bus master is granted the bus, but does not transfer data. 01 busy busy transfer is used to insert an idle cycle in the middle of a burst of transfers. 10 nonseq nonsequential transfer indicates the ?st transfer of a burst or a single transfer. 11 seq sequential transfer is used for subsequent transfers in a burst. the control information is identical to the previous transfer. the address is equal to the address of the previous transfer plus the size (in bytes). for wrapping bursts, the address of the transfer wraps at the address boundary equal to the size (in bytes) multiplied by the number of beats in the transfer (either 4, 8, or 16). 5-4 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 5.2 shows usage of three transfer types. the ?st transfer is the start of a burst; it is nonsequential. the master is unable to perform the second transfer of the burst immediately. it uses a busy transfer to delay the start of the next transfer. in this example, the master only requires one cycle before it is ready to start the next transfer in the burst, which completes with no wait states. the master performs the third transfer of the burst immediately, but this time the slave is unable to complete and uses hready to insert a single wait state. the ?al transfer of the burst completes with zero wait states. figure 5.2 transfer type examples 5.2.2 burst types the ahb protocol de?es four, eight, and 16-beat bursts as well as unde?ed length bursts and single transfers. the protocol also supports incrementing and wrapping bursts. all ARM966E-S bursts are de?ed as incrementing bursts of unde?ed length (incr). nonseq clk htrans[1:0] haddr[31:0] hwdata[31:0] hready hrdata[31:0] busy data (a) seq seq seq 0x20 0x24 0x24 0x28 0x2c incr data (0x20) data (0x24) data (0x28) data (0x2c) hburst[2:0] data (0x20) data (0x24) data (0x28) data (0x2c) ahb interface signals 5-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. hburst[2:0] determine the burst type as indicated in table 5.2. the ARM966E-S supports single and incr types only (hburst[2:0] = 0b000 and 0b001). incrementing bursts access sequential locations; the address of each transfer in the burst is just an increment of the previous address. bursts must not cross a 1 kbyte address boundary. an incrementing burst can be of any length, but the upper limit is set by the fact that the address must not cross the 1 kbyte boundary. single transfers can be done using an unspeci?d length incrementing burst that has a burst length of one. all transfers within a burst must be aligned to the address boundary equal to the size of the transfer. for example, word transfers must be aligned to word address boundaries (haddr[1:0] = 00), and halfword transfers must be aligned to halfword address boundaries (haddr0 = 0). 5.2.3 control signals the control signals provide additional information regarding the transfer. these signals include hwrite, hsize[2:0], hprot[3:0], hready, and hresp[1:0]. 5.2.3.1 hwrite hwrite determines the transfer direction. when high, hwrite indicates a write transfer; the master broadcasts data on the write data bus, hwdata[31:0]. when hwrite is low, a read transfer is performed. the slave places the data on the read data bus, hrdata[31:0]. table 5.2 burst signal encoding hburst[2:0] burst type description 000 single single transfer 001 incr incrementing burst of unspeci?d length 010?11 not supported 5-6 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 5.2.3.2 hsize[2:0] hsize[2:0] indicate the transfer size. the size is used in conjunction with the hburst[2:0] signals to determine the address boundary for wrapping bursts. the ARM966E-S only supports transfer sizes of byte, halfword, and word (hsize[2:0] = 0b000, 0b001, and 0b010). 5.2.3.3 hprot[3:0] hprot[3:0] are the protection control signals. they provide additional information about a bus access and are primarily intended for use by any module that wishes to implement some level of protection. hprot0 indicates whether the instruction is an opcode fetch or data access. hprot1 indicates whether the transfer is a supervisor mode access or user mode access. for bus masters with an mmu, hprot2 indicates whether the current access is bufferable. hprot3 is tied to 0, indicating noncacheable. table 5.3 size encoding hsize[2:0] transfer size description 000 8 bits byte 001 16 bits halfword 010 32 bits word 011?11 not supported ahb interface signals 5-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. not all bus masters can generate accurate protection information because they do not contain suf?ient information about the nature of the transfer. therefore slaves should not use hprot[3:0] unless absolutely necessary. 5.2.3.4 hready hready is used to extend the data portion of an ahb transfer. when low, hready indicates the transfer is to be extended; when high, hready indicates the transfer can complete. a typical slave uses hready to insert the appropriate number of wait states into the transfer. to ensure accurate bus access latency, every slave must have a predetermined number of wait states it inserts before backing off the bus. it is recommended that slaves do not insert more than 16 wait states to prevent any single access locking the bus for a large number of clock cycles. 5.2.3.5 hresp[1:0] the hresp[1:0] signals indicate the transfer response: okay, error, split, or retry. when the transfer completes with an okay response on hresp[1:0], the transfer was successfully completed. the okay response is also table 5.4 protection signal encoding hprot3 cacheable hprot2 bufferable hprot1 supervisor hprot0 data/opcode description 0 opcode fetch 1 data access 0 user access 1 supervisor access 0 not bufferable 1 bufferable 0 not cacheable 5-8 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. used for any additional cycles that are inserted with hready low, prior to giving one of the other three responses. when it is necessary for a slave to insert a number of wait states prior to deciding what response to give, then it must drive the response to okay. a slave uses the error response to indicate to the bus master that some form of error condition with the associated transfer has occurred. typically, this response is used for a protection error, such as an attempt to write to a read-only memory location. a two-cycle response is required for an error condition. the split and retry response combinations allow slaves to delay the completion of a transfer, but free up the bus for use by other masters. these response combinations are usually only required by slaves that have a high access latency and can make use of these response codes to ensure that other masters are not prevented from accessing the bus for long periods of time. the retry response indicates the transfer has not yet completed, so the bus master should retry the transfer. the master should continue to retry the transfer until it completes. a two-cycle retry response is required. the split response indicates the transfer has not yet completed. the bus master must retry the transfer when it is next granted the bus. the slave will request access to the bus on behalf of the master when the transfer can be completed. a two-cycle split response is required. 5.2.4 data buses because the ahb interface does not implement 3-state drivers, it contains separate read and write data buses. 5.2.4.1 hwdata[31:0] the bus master drives the write data bus during write transfers. if the transfer is extended, then the bus master must hold the data valid until the transfer completes, as indicated by hready high. all transfers must be aligned to the address boundary equal to the size of the transfer. for example, word transfers must be aligned to word ahb interface signals 5-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. address boundaries (haddr[1:0] = 00), halfword transfers must be aligned to halfword address boundaries (haddr0 = 0). for transfers that are narrower than the width of the bus, for example, a 16-bit transfer on a 32-bit bus, then the bus master only has to drive the appropriate byte lanes. the slave is responsible for selecting the write data from the correct byte lanes. table 5.5 and table 5.6 show which byte lanes are active for little-endian and big-endian systems, respectively. burst transfers that have a transfer size less than the width of the data bus have different active byte lanes for each beat of the transfer. table 5.5 active byte lanes for a 32-bit little-endian data bus transfer size address offset data[31:24] data[23:16] data[15:8] data[7:0] word 0 x x x x halfword 0 x x halfword 2 x x byte 0 x byte 1 x byte 2 x byte 3 x 5-10 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the active byte lane also depends on the endianess of the system, but the ahb does not specify the required endianess. therefore all master and slaves must have the same endianess. 5.2.4.2 hrdata[31:0] the appropriate slave drives the read data bus during read transfers. if the slave extends the read transfer by holding hready low, then the slave only needs to provide valid data at the end of the ?al cycle of the transfer, as indicated by hready high. for transfers that are narrower than the width of the bus, the slave only needs to provide valid data on the active byte lanes, as indicated in table 5.5 and table 5.6. the bus master is responsible for selecting the data from the correct byte lanes. a slave only has to provide valid data when a transfer completes with an okay response. error, retry, and split responses do not require valid read data. 5.2.5 endianess for the system to function correctly, all modules must use the same endianess. the same is true of any data routing or bridges. dynamic endianess is not supported. table 5.6 active byte lanes for a 32-bit big-endian data bus transfer size address offset data[31:24] data[23:16] data[15:8] data[7:0] word 0 x x x x halfword 0 x x halfword 2 x x byte 0 x x byte 1 x byte 2 x byte 3 x ahb clocking 5-11 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. only modules that are used in a wide variety of applications should support both big- and little-endian ordering. either a con?uration pin or internal control bit can select between the two endian settings. 5.3 ahb clocking the ARM966E-S uses a single clock, clk. in many systems, it might be desirable for the ARM966E-S to run at a higher frequency than the ahb system bus. to support this option, the ARM966E-S provides a clock enable, hclken. hclken is high for a single clk period and signi?s the rising edge of the ahb clock hclk. clk and hclk must be synchronous. the skew between clk and hclk must be minimized. note that hclk is not used by the core and might not be used in all implementations. figure 5.3 shows the relationship between clk, hclken, and hclk. figure 5.3 ahb clock relationships 5.4 ahb operation before an ahb transfer can begin, the bus master must be granted access to the bus. this process is started by the master asserting a request signal to the arbiter. then the arbiter indicates when the master is granted use of the bus. clk hclken hclk ahb outputs from ARM966E-S ahb inputs to ARM966E-S 5-12 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. when a master is granted the bus, its address and control signals are driven to all slaves. these signals provide information on the address, direction, and width of the transfer, as well as an indication when the transfer forms part of an incrementing burst. incrementing bursts do not wrap at address boundaries. a write data bus moves data from the master to a slave, while a read data bus moves data from a slave to the master. every transfer consists of an address/control cycle followed by one or more cycles for the data. the address cannot be extended and therefore all slaves must sample the address during this time. the data, however, can be extended using the hready signal. when low, this signal causes wait states to be inserted into the transfer and allows extra time for the slave to provide or sample data. during a transfer, the slave shows the status using the response signals, hresp[1:0]. the okay response indicates that the transfer is progressing normally, and, when hready goes high, shows the transfer has completed successfully. the other possible transfer responses are error, retry, and split. the error response indicates that a transfer error occurred and the transfer was unsuccessful. both split and retry transfer responses indicate that the transfer cannot complete immediately, but the bus master should continue to attempt the transfer. in normal operation, a master is allowed to complete all the transfers in a particular burst before the arbiter grants another master access to the bus. however, in order to avoid excessive arbitration latencies, it is possible for the arbiter to break up a burst and in such cases, the master must rearbitrate for the bus in order to complete the remaining transfers in the burst. 5.5 basic transfers an ahb transfer consists of two distinct sections, the address and the data. the address lasts only a single cycle, while the data might require several cycles, using the hready signal. basic transfers 5-13 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 5.4 shows the simplest transfer with no wait states. the master drives the address and control signals onto the bus after the rising edge of clk. the slave then samples the address and control information on the next rising edge of the clock. after the slave has sampled the address/control, it can start to drive the appropriate response. the bus master samples the response on the third rising edge of the clock. figure 5.4 simple transfer this example shows how the address and data phases of the transfer occur during different clock periods. in fact, the address phase of any transfer occurs during the data phase of the previous transfer. this overlapping of address and data is fundamental to the pipelined nature of the bus. it allows for high-performance operation while still providing adequate time for a slave to provide the response to a transfer. figure 5.5 shows a transfer with wait states. a slave can insert wait states into any transfer, allowing additional time for completion. for write operations, the bus master holds the data stable throughout the extended cycles. for read operations, the slave does not have to provide valid data until the transfer is about to complete. a address phase control data (a) data (a) data phase clk haddr[31:0] control hwdata[31:0] hready hrdata[31:0] 5-14 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 5.5 transfer with wait states when a transfer is extended with wait states, it ends up extending the address phase of the next transfer. figure 5.6 shows three transfers to unrelated addresses: a, b, and c. the transfers to addresses a and c both have zero wait states, but the transfer to address b has one wait state. extending the data phase of the transfer to address b extends the address phase of the transfer to address c. figure 5.6 multiple transfers a clk haddr[31:0] control hwdata[31:0] hready hrdata[31:0] control data (a) data (a) address phase data phase a clk haddr[31:0] control hwdata[31:0] hready hrdata[31:0] data (a) b c control (a) control (c) data (b) control (b) data (b) data (c) data (a) data (c) burst operations 5-15 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 5.6 burst operations this section provides examples of burst operations the ARM966E-S supports. 5.6.1 early burst termination sometimes a burst is not allowed to complete. to determine when a burst has terminated early, the slave should monitor the htrans signals and ensure that after the start of the burst, every transfer is sequential or busy. occurrence of a nonsequential or idle transfer indicates a new burst has started, and thus the previous burst must have been terminated. if a bus master cannot complete a burst because it loses ownership of the bus, then it must rebuild the burst appropriately when it next gains access to the bus. for example, if a master has only completed one beat of a four-beat burst, then it must use an unde?ed length burst to perform the remaining three transfers. 5.6.2 burst operation example figure 5.7 shows incrementing bursts of unde?ed length. the ?ure shows two bursts. the ?st burst is two transfers starting at address 0x20; the second burst is three transfers starting at address 0x5c. the ?st burst consists of halfword transfers, so the addresses increment by two. the second burst consists of word transfers, so the addresses increment by four. 5-16 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 5.7 incrementing bursts with unde?ed lengths 5.7 slave transfer responses after a master has started a transfer, the slave then determines how the transfer should progress. no provision is made within the ahb speci?ation for a bus master to cancel a transfer once it has started. whenever a slave is accessed, it must provide a response that indicates the status of the transfer. hready is used to extend the transfer. it works in combination with the response signals, hresp[1:0], which provide the status of the transfer. the options that the slave has on how it can complete the transfer are: ? complete the transfer immediately ? insert one or more wait states to allow time to complete the transfer ? signal an error to indicate that the transfer has failed ? delay the completion of the transfer, but allow the master and slave to back off the bus, leaving it available for other transfers nonseq t1 t2 t3 t4 t5 t6 t7 t8 seq seq seq nonseq control for burst size = word data (0x20) data (0x22) data (0x60) data (0x20) data (0x22) data (0x5c) data (0x60) data (0x64) clk htrans[1:0] hwdata[31:0] hready hrdata[31:0] hburst[2:0] hwrite hsize[2:0] hprot[3:0] 0x20 0x60 0x64 0x22 0x5c incr incr control for burst size = halfword data (0x64) data (0x5c) haddr[31:0] slave transfer responses 5-17 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 5.7.1 two-cycle response only an okay response can be given in a single cycle. the error, retry, and split responses require at least two cycles. to complete with any of these three responses, in the cycle previous to the last cycle, the slave drives hresp[1:0] to indicate error, retry, or split while driving hready low to extend the transfer for an extra cycle. in the ?al cycle, the slave drives hready high to end the transfer, while continuing to drive hresp[1:0]. if the slave needs more than two cycles to provide the error, retry, or split response, then additional wait states can be inserted at the start of the transfer. during this time, the hready signal is low and the response must be set to okay. the two-cycle response is required because of the pipelined nature of the bus. by the time a slave starts to issue an error, retry, or split response, then the address for the following transfer has already been broadcast onto the bus. the two-cycle response allows suf?ient time for the ARM966E-S to cancel this address and drive htrans[1:0] to idle before the start of the next transfer. for the retry or split responses, the following transfer must be cancelled because it must not take place before the current transfer has completed. however, for the error response, where the current transfer is not repeated, it is optional whether or not the next transfer is allowed to complete. figure 5.8 shows an example of a retry operation. the ARM966E-S starts with a transfer to address a. before the response is received for this transfer, the ARM966E-S moves the address to a + 4. however, the slave at address a is unable to complete the transfer immediately; therefore it issues a retry or split response. this response indicates to the ARM966E-S that the transfer at address a is unable to complete. so the transfer at address a + 4 is cancelled and replaced with an idle transfer. 5-18 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 5.8 transfer with retry response figure 5.9 shows a transfer where the slave requires one cycle to decide on the response it is going to give (during which time hresp indicates okay). then the slave ends the transfer with a two-cycle error response. figure 5.9 error response 5.7.2 error response if a slave provides an error response, then the ARM966E-S can choose to cancel the remaining transfers in the burst. however, this requirement is not strict; it is also acceptable for the ARM966E-S to continue the remaining transfers in the burst. nonseq clk htrans[1:0] haddr[31:0] hwdata[31:0] hready hresp[1:0] data (a) seq idle nonseq a a+4 a okay retry retry a clk control hwdata[31:0] hready hresp[1:0] data (a) error error okay haddr[31:0] control hrdata[31:0] slave transfer responses 5-19 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 5.7.3 retry responses the retry response provides a mechanism for slaves to release the bus when they are unable to supply data for a transfer immediately. this mechanism allows the transfer to ?ish on the bus. therefore a higher priority ARM966E-S can get access to the bus. after a retry has occurred, the arbiter continues to use the normal priority scheme. only masters that have a higher priority gain access to the bus. the ARM966E-S continues to request the bus and attempts the transfer until it either has completed successfully or has been terminated with an error response. 5.7.4 split responses the split response provides a mechanism for slaves to release the bus when they are unable to immediately supply data for a transfer. this mechanism allows the transfer to ?ish on the bus. therefore a higher priority ARM966E-S can get access to the bus. after a split has occurred, the arbiter adjusts the priority scheme so that any other master requesting the bus gets access, even if it has a lower priority. the slave requests access to the bus on behalf of the master when the transfer can complete. the ARM966E-S will continue to request the bus and attempt the transfer until it is either completed successfully or terminated with an error response. 5-20 ahb interface unit rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. ARM966E-S microprocessor core technical manual 6-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 6 write buffer this chapter describes the ARM966E-S write buffer. this chapter contains the following sections: ? section 6.1, ?ntroduction ? section 6.2, ?ormal operation ? section 6.3, ?ull write buffer ? section 6.4, ?nbuffered writes ? section 6.5, ?ead-lock-write ? section 6.6, ?ead to write-posted address ? section 6.7, ?rite buffer nonrecoverable error and abort conditions 6.1 introduction the ARM966E-S write buffer enhances system performance. it decouples the processor from a slower memory interface during processor writes. the write buffer allows the core to perform writes without waiting for access to the ahb bus. the write buffer consists of a 12-entry fifo. each entry can be either address or data, where the use of each entry is speci?d by an address/data ?g. each address entry is tagged with the size of the transfer as indicated by the arm9e-s processor core (byte, halfword, or word). the write buffer is ?shed at reset. any entries still in the buffer when reset is asserted are lost. to enable the write buffer, write to cp15 register 1. to drain the write buffer, write to cp15 register 7. 6-2 write buffer rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 6.2 normal operation the write buffer only buffers writes to areas of memory that are identi?d as being bufferable (see the memory map on page 3-5). provided that the write buffer is enabled and the processor performs a write to a bufferable area, the data is placed in the write buffer. the write buffer is then marked as not empty . once data is in the write buffer, it is always written, even if it is subsequently disabled, unless a reset occurs. a write buffer flush condition is de?ed as one of the following: ? reset ? the write buffer is full and the processor attempts another write ? an unbuffered write occurs ? a read-lock-write instruction occurs ? a read to address was previously posted, but is not yet written to memory note: the ARM966E-S does not support reordering and merging of writes. in cases, for example, where there are two nonsequential writes to two adjacent but not incremental addresses (such as 0x84 followed by 0x80), they could be reordered and merged into a single two-word burst transfer, but software might have intended the write to 0x84 to occur before the write to 0x80. this feature also increases the complexity of the write buffer. if the ARM966E-S enters wait-for-interrupt mode, then the write buffer continues to perform accesses until it is empty. read-modify-write sequences to buffered ahb regions are treated as unbuffered accesses. 6.3 full write buffer when full, the write buffer must provide a response to the system controller to prevent lost data. unbuffered writes 6-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. when the write buffer is full and the processor attempts a buffered write, the ?st buffer entry must be written to memory to make space for the new write entry. if the ?st write buffer entry was from a store multiple, then all of the write cycles needed to complete the store multiple are performed before the new write cycle is placed in the buffer. 6.4 unbuffered writes an unbuffered write to the ahb bus causes the write buffer to drain before the write takes place. flushing ensures the writes are in the order the software intended. the order is important, for example, when setting up some parameters before triggering an external event. during this time, the core must be stalled to prevent execution advancing. 6.5 read-lock-write the read-lock-write sequence is atomic. it asserts the hlock signal during the transfer to prevent any other bus masters from breaking the sequence. the write phase of the sequence is treated as an unbuffered write, which means that the write buffer needs to be ?shed before the write can complete. the write buffer is ?shed before starting the read phase of the sequence. therefore only the memory bus is locked for the minimum number of cycles (the single read followed by single write cycles). 6.6 read to write-posted address if a read occurs to an address contained in the write buffer, then the buffer must be ?shed before allowing the read to propagate to the bus. during this time, the core must stall to prevent execution from advancing. 6.7 write buffer nonrecoverable error and abort conditions buffered writes cannot be successfully aborted. when an error response to a transfer on the ahb bus occurs, the write buffer drives the dabort signal to the processor. however, the data abort handler 6-4 write buffer rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. cannot correlate the processor s present state to the bus cycle that caused the error. this event is considered to be a nonrecoverable error condition. ARM966E-S microprocessor core technical manual 7-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 7 system controller this chapter describes the ARM966E-S system controller, which arbitrates between the instruction ram, data ram, and the ahb bus interface unit. this chapter contains the following sections: ? section 7.1, ?peration ? section 7.2, ?lock control 7.1 operation the system controller oversees the interactions between the instruction/data rams and the ahb bus interface unit. the system controller prevents the processor core from advancing if its memory requests cannot be satis?d simultaneously (for example, accessing ahb memories while executing code from the tightly coupled ram). the system controller prevents these occurrences from happening by controlling the internal system clock enable signal (clken) to the arm9e-s core. when the core is accessing the on-chip memory, stall cycles are required when: ? there are simultaneous data accesses and instruction fetches to the instruction memory ? a write to the ram is followed by a read of the same memory if the write buffer is full, when the ARM966E-S writes to a bufferable region of memory (see memory map on page 3-5), the system controller must stall it to prevent data loss. when the address decoders indicate an ARM966E-S read misses the on-chip memory, the system controller must stall the core until the write buffer is empty and maintain the stall until the access to the ahb is complete. 7-2 system controller rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. when the core performs a nonbufferable write that misses the on-chip memory as indicated by the address decoders, the system controller must stall the core until the write buffer is empty and maintain the stall until the access to the ahb is complete. 7.2 clock control when accessing the ahb bus for accesses that do not use the write buffer, the internal clock enable clken must include the effects of hclken, hready, and hgrant to ensure that the core is synchronized to the ahb bus. the ahb biu must inform the system controller when each transfer has completed. the system controller determines when an external access is being performed and quali?s the internal clock enables with hclken from the ahb interface. using hclken effectively slows down the operation of the ARM966E-S to the ahb bus frequency. ARM966E-S microprocessor core technical manual 8-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 8 tightly coupled ram this chapter describes the instruction and data rams within the ARM966E-S design. it contains the following sections: ? section 8.1, ?ightly coupled memory (tcm) overview ? section 8.2, ?rm966e-s sram requirements ? section 8.3, ?nabling the sram ? section 8.4, ?rm966e-s sram wrapper ? section 8.5, ?xample sram interfaces 8.1 tightly coupled memory (tcm) overview the ARM966E-S supports synchronous sram for the tightly coupled ram. the tcm interfaces are zero wait state, and data must be returned in a single clock cycle. the instruction and data rams can be of any size up to 512 kbytes. the instruction ram and data ram are independent and thus can be different sizes. 8.2 ARM966E-S sram requirements the tightly-coupled sram is built from blocks of asic library compiled sram. the instruction sram (i-sram) and data sram (d-sram) can each be any size from 0 bytes to 512 kbytes; the size must be an integer power of two. the i-sram and d-sram can have different sizes. to allow the i-sram to be initialized and for access to literal tables during execution, the data interface of the ARM966E-S must be able to access the i-sram. thus the instruction and data addresses must be multiplexed before entering the i-sram, and the instruction data is 8-2 tightly coupled ram rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. routed both to the instruction and data interfaces of the core. see figure 1.1 on page 1-3 for details of this data and address multiplexing. the ARM966E-S supports the use of synchronous sram. the sram control has been implemented in a way that expects the compiled sram memory cells to return read data to the ARM966E-S in a single cycle. this requirement applies to both the i-sram and d-sram. see figure 8.1 for a typical read cycle (i-sram shown). figure 8.1 sram read cycle during normal program execution, the instruction and data interfaces of the ARM966E-S can be active simultaneously. in this case, both srams can be simultaneously accessed allowing the core to continue execution without any stall cycles. there are cases, however, where stall cycles are encountered when accessing the sram. 8.3 enabling the sram there are two mechanisms for controlling the sram enable: ? both i-sram and d-sram can be enabled or disabled during reset by the input initram ? the i-sram and d-sram can be individually enabled or disabled through software mcr instructions to cp15. 8.3.1 using initram to enable sram two resets are described in the following subsections, depending on the state of the initram input. clk inmreq ia[31:1] instr[31:0] sram access time addr a instr (a) enabling the sram 8-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 8.3.1.1 reset with initram low initram allows the ARM966E-S to boot with both sram blocks either enabled or disabled. if initram is held low during reset, the ARM966E-S comes out of reset with both srams disabled. all accesses to i-sram and d-sram space go to the ahb. the i-sram and d-sram can then be individually or jointly enabled by writing to the cp15 control register (register 1). 8.3.1.2 reset with initram high if initram is held high during reset, both sram blocks are enabled when the ARM966E-S comes out of reset. this case is normally used for a warm reset where the sram has already been programmed before nreset is asserted to the ARM966E-S. in this case, the sram contents are preserved and the ARM966E-S can run directly from the tightly coupled sram following reset. either one or both srams can be further disabled or enabled by writing to the cp15 control register. impor tant: if initram is held high during a cold reset (the sram has not previously been initialized), vinithi must be held high to ensure that the ARM966E-S boots from 0xffff.0000, which is in ahb address space and is outside the sram address space. this boot location is necessary because if vinithi is low, the ARM966E-S will attempt to boot from 0x0000.0000, which selects the uninitialized i-sram. 8.3.2 using cp15 control register to enable sram when out of reset, the state of the cp15 control register controls the behavior of the tightly coupled sram. see section 3.7.2, ?p15 registers, page 3-9 for details on how to read and write the cp15 control register. 8.3.2.1 enabling the i-sram to enable the i-sram, set bit 12 (the i bit) of the cp15 control register. this register must be accessed in a read-modify-write fashion to preserve the contents of the bits not being modi?d. when the i-sram has been enabled, all future arm9e-s instruction fetches and data 8-4 tightly coupled ram rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. accesses to the i-sram address space access the i-sram. figure 3.2 on page 3-5 shows the i-sram address space. enabling the i-sram greatly increases the performance of the ARM966E-S because most accesses to it have no stall cycles, whereas accessing the ARM966E-S through the ahb can cause several stall cycles for each access. you must ensure that the i-sram is appropriately initialized before it is enabled and used to supply instructions to the ARM966E-S. if the core tries to execute instructions from uninitialized i-sram, the behavior is unpredictable. 8.3.2.2 disabling the i-sram to disable the i-sram, clear bit 12 of the cp15 control register. when the i-sram has been disabled, all further ARM966E-S instruction fetches access the ahb. if the ARM966E-S performs a data access to the i-sram address space, an ahb access is performed. figure 3.2 on page 3-5 shows the i-sram address space. the contents of the i-sram are preserved when it is disabled. if it is re-enabled, accesses to previously initialized i-sram locations returns the preserved data. 8.3.2.3 enabling the d-sram to enable the d-sram, set bit 2 (the d bit) of the cp15 control register. when the d-sram has been enabled, all future read and write accesses to the d-sram address space cause the d-sram to be accessed. figure 3.2 on page 3-5 shows the d-sram address space. 8.3.2.4 disabling the d-sram to disable the d-sram, clear bit 2 of the cp15 control register. when the d-sram is disabled, all further reads and writes to the d-sram address space access the ahb. figure 3.2 on page 3-5 shows the d-sram address space. read and write accesses to d-sram address space use the d-sram (if enabled) or access the ahb. ARM966E-S sram wrapper 8-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 8.4 ARM966E-S sram wrapper the ARM966E-S allows you to have control over the size of the i-sram and d-sram (up to a maximum of 512 kbytes each). it is not possible to have a single generic interface between the ARM966E-S and the sram, due to the large number of differing compiled sram that can be integrated into an ARM966E-S system, potentially each with a unique interface. to ease the task of integrating differing sram into the ARM966E-S, an interface wrapper block has been developed to ensure that when wrapped, the sram provides a standard interface to the ARM966E-S sram control. section 8.5, ?xample sram interfaces, provides an example sram wrapper with three example interfaces. study these examples and decide which is most appropriate for the type of sram available. a script is provided that automates any required changes. the ram interface rtl allows you to trade off speed against power performance so that you can tailor the ARM966E-S to suit a particular requirement. there are ?e sram modules instantiated at the top-level of the ARM966E-S. figure 8.2 shows the structure of these three modules. 8-6 tightly coupled ram rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 8.2 ARM966E-S sram hierarchy ramctrl.v contains the ram control logic that is partner-independent. this logic is ?ed. iramif.v and dramif.v generate the sram-speci? chipselect, writeenable, and bytewrite signals. your own library rams are instantiated inside instrram.v and dataram.v . 8.5 example sram interfaces the example wrapper contains three ram interface examples. all of the interface modi?ations are done in the iramif.v and the dramif.v blocks for the i-sram and d-sram, respectively. the example sram interfaces are: ? section 8.5.1, ?nesegx32 ? section 8.5.2, ?oursegx32 ? section 8.5.3, ?oursegx8 note: the examples shown here are for 32-kbyte i-sram (8 kwords x 4 bytes). the interface for d-sram is identical. iramif.v bist.v iram.v instrram.v bist.v dram.v dramif.v dataram.v ramctrl.v ictrl.v dctrl.v dma example sram interfaces 8-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 8.5.1 onesegx32 figure 8.3 shows the simplest i-sram interface. to use this example, the sram must consist of a single word-wide ram that has byte-write control. only single chipselect and writeenable signals are required. figure 8.3 onesegx32 interface 8.5.2 foursegx32 use the example shown in figure 8.4 when it is not possible to construct the sram from a single physical block due to either layout constraints or generator constraints, or because a single sram segment does not meet timing constraints. ictrl.v iramif.v 8k x 32 bytewrite[3:0] ramaddr[12:0] writeenable chipselect irdata[31:0] 8-8 tightly coupled ram rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 8.4 foursegx32 interface separate chip select signals are required for each sram block. ? the generation of separate chip select signals for each sram block ensures good power performance, because only the segment being accessed is enabled. ? the sram address is 11 bits in this example (compared with the 13 bit address in section 8.5.1, ?nesegx32?. ramaddr[12:11] are used to generate separate chip selects for each segment. if it is not possible to have separate chip select signals for each block of ram, for example, if the ram is asynchronous, then separate write enable signals are required for each segment. the use of asynchronous rams is not recommended due to the increased power consumption of this solution. note: the wrapper rtl does not support asynchronous rams. 8.5.3 foursegx8 figure 8.5 shows that the sram needs to be split into four-byte wide segments where an sram does not support byte writes. in order to give ictrl.v iramif.v 2k x 32 bytewrite[3:0] ramaddr[10:0] writeenable chipselect[3:0] 2k x 32 2k x 32 2k x 32 irdata[31:0] [2] [3] [127:96] [95:64] [1] [0] [63:32] [31:0] outputselect[1:0] example sram interfaces 8-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. an example of the most complex interface possible, figure 8.5 assumes that each byte-wide sram needs to be split into four blocks (see word-wide sram in section 8.5.2, ?oursegx32,?. in section 8.5.2, ?oursegx32, the sram address is 11 bits. bits [12:11] of the address are used to decode which of the four word-wide rams is selected. in figure 8.5, bytewrite[3:0] is used (inside iramif.v ) to decode each word-wide chip select into four separate chip select signals, one for each byte of the word. 8-10 tightly coupled ram rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 8.5 foursegx8 interface ictrl.v iramif.v 2k x 8 bytewrite[3:0] ramaddr[10:0] writeenable chipselect[15:0] 2k x 8 2k x 8 2k x 8 irdata[31:0] [8] [12] [4] [0] outputselect[1:0] 2k x 8 2k x 8 2k x 8 2k x 8 [11] [15] [7] [3] 2k x 8 2k x 8 2k x 8 2k x 8 [10] [14] [6] [2] 2k x 8 2k x 8 2k x 8 2k x 8 [9] [13] [5] [1] 8 32 byte 3 byte 2 byte 1 byte 0 ARM966E-S microprocessor core technical manual 9-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 9 external coprocessor interface this chapter describes the ARM966E-S external coprocessor interface. the ARM966E-S connects to on-chip coprocessors through this interface. this interface supports all types of coprocessor instructions. this chapter contains the following sections: ? section 9.1, ?verview ? section 9.2, ?oprocessor instruction execution ? section 9.3, ?rivileged instructions ? section 9.4, ?talling and interrupts 9.1 overview coprocessors determine which instructions they need to execute by a pipeline follower in the coprocessor. as each instruction arrives from memory, it enters both the arm9e-s pipeline and the coprocessor s pipeline. to avoid a critical path for the instruction being latched by the coprocessor, the coprocessor s pipeline operates one clock cycle later than the arm9e-s core pipeline. however, the ARM966E-S also includes a mechanism that stalls the pipeline so the processor can catch up with the external coprocessor pipeline. so, in effect, both pipelines are synchronized. the arm9e-s core informs the coprocessor when instructions move from decode into execute, and whether the instruction needs to be executed. to enable coprocessors to continue execution of coprocessor data operations while the arm9e-s core pipeline is stalled, the coprocessor receives the clk clock, and a clock enable signal cpclken. if cpclken is low on the rising edge of cpclk, then the arm9e-s core pipeline is stalled and the coprocessor pipeline should not advance. figure 9.1 indicates the timing for these signals and when the 9-2 external coprocessor interface rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. coprocessor pipeline should advance its state. coprocessor clock shows the result of anding clk with cpclken; this is one technique for generating a clock that re?cts the arm9e-s core pipeline advancing. figure 9.1 clk and cpclken timing 9.2 coprocessor instruction execution there are three classes of coprocessor instructions: ldc/stc, mcr/mrc, and cdp. the following subsections give examples of how a coprocessor should execute these instruction classes. 9.2.1 ldc/stc instructions the cycle timing for this operation is shown in figure 9.2 in this example four words of data are transferred. the number of words transferred is determined by how the coprocessor drives the chsde[1:0] and chsex[1:0] buses. clk cpclken coprocessor clock coprocessor instruction execution 9-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 9.2 ldc/stc cycle timing as with all other instructions, the arm9e-s core performs the main decode off the rising edge of the clock during the decode stage. from this, the core commits to executing the instruction and so performs an instruction fetch. the coprocessor s instruction pipeline keeps in step with the arm9e-s core by monitoring ncpmreq, which is a latched copy of the arm9e-s core instruction memory request signal inmreq. whenever ncpmreq is low, an instruction fetch is occurring and cpinstr is updated with the fetched instruction in the next cycle. thus the instruction currently on cpinstr should enter the decode stage of the coprocessor pipeline, and the instruction in the decode stage of the coprocessor s pipeline should enter its execute stage. during the execute stage, the condition codes are combined with the ?gs to determine whether the instruction really executes or not. the output cppass is asserted high if the instruction in the execute stage of the coprocessor pipeline is a coprocessor instruction and has passed its condition codes. if a coprocessor instruction stalls, then cppass is asserted on every cycle until the coprocessor instruction is executed. if an interrupt occurs during stalling then cppass is driven low and the coprocessor should stop the coprocessor instruction execution. go go last ignored cpclk ncpmreq cppass cplatecancel chsde[1:0] chsex[1:0] cpdout[31:0] ldc cpdin[31:0] stc go decode execute execute execute execute memory write go go go last processor pipeline 9-4 external coprocessor interface rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the cplatecancel output is used to cancel a coprocessor instruction when the instruction preceding it causes a data abort. this output is valid on the rising edge of clk on the cycle after the coprocessor instruction s ?st execute cycle. on the rising edge of the clock, the arm9e-s processor core examines the coprocessor handshake signals chsde[1:0] and chsex[1:0]. if a new instruction is entering the execute stage in the next cycle, then the core examines chsde[1:0]. if the coprocessor instruction currently in execution requires another execute cycle, then the core examines chsex[1:0]. the handshake signals encode one of four states: ? absent if there is no coprocessor attached that can execute the coprocessor instruction, then the handshake signals indicate the absent state, and the arm9e-s core takes the unde?ed instruction trap. ? wait if there is a coprocessor attached that can handle the instruction, but not immediately, then the coprocessor handshake signals are driven to indicate that the arm9e-s core should stall until the coprocessor can catch up. in this case, the arm9e-s core loops in an idle state waiting for chsex[1:0] to be driven to another state, or for an interrupt to occur. if chsex[1:0] changes to absent then the unde?ed instruction trap is taken. if chsex[1:0] changes to go or last, then the instruction proceeds as described below. if an interrupt occurs, then the arm9e-s core is forced out of the stalled state. this condition is indicated to the coprocessor by a low transition on cppass. the instruction is restarted at a later time. the coprocessor should not commit to the instruction (change any of the coprocessor s states) until it has seen cppass high when the handshake signals indicate the go or last condition. ? go the go state indicates that the coprocessor can execute the instruction immediately, and that it requires another cycle of execution. both the arm9e-s core and the coprocessor must also consider the state of the cppass signal before actually committing to the instruction. for an ldc or stc instruction, the coprocessor instruction drives the handshake signals with go when two or more coprocessor instruction execution 9-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. words still need to be transferred. when only one more word is required, the coprocessor drives the handshake signals with last. ? last if an ldc or stc instruction is for more than one item of data, then after stalling, the coprocessor might drive the coprocessor handshake signals with a number of go states, and in the cycle last, where last indicates that the next transfer is the ?al one. if there is only one transfer then the sequence would be: [wait,[wait,...]],last. 9.2.2 mcr/mrc instructions these cycles look very similar to stc/ldc cycles. figure 9.3 shows an example with a stall (wait) state. first ncpmreq is driven low to denote that the instruction on cpinstr is entering the decode stage of the pipeline. this low state causes the coprocessor to decode the new instruction and drive chsde[1:0] as required. in the next cycle ncpmreq is driven low to denote that the instruction has now been issued to the execute stage. if the condition codes pass (thus the instruction is to be executed), then cppass is driven high and the chsde[1:0] handshake bus is examined (it is ignored in all other cases). for any successive execute cycles, the chsex[1:0] handshake bus is examined. when the last condition is observed, the instruction is committed. in the case of an mcr instruction, the cpdout[31:0] bus is driven with the register data during the coprocessor write stage. in the case of an mrc instruction, cpdin[31:0] is sampled at the end of the arm9e-s memory stage and is written to the destination register during the next cycle. 9-6 external coprocessor interface rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 9.3 mcr/mrc cycle timing 9.2.3 interlocked mcrs if the data for an mcr operation is not available inside the arm9e-s core pipeline during its ?st decode cycle, then the arm9e-s core pipeline interlocks for one or more cycles until the data is available. an example of this is where the register being transferred is the destination from a preceding ldr instruction. in this situation, the mcr instruction enters the decode stage of the coprocessor pipeline, and then remains there for a number of cycles before entering the execute stage. figure 9.4 is an example of an interlocked mcr. wait last ignored cpclk ncpmreq cppass cplatecancel chsde[1:0] chsex[1:0] cpdout[31:0] mcr cpdin[31:0] mrc decode execute execute memory write wait last processor pipeline cop data cop data coprocessor instruction execution 9-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 9.4 interlocked mcr 9.2.4 cdp instructions cdp instructions normally execute in a single cycle. like all the previous cycles, ncpmreq is driven low to signal when an instruction is entering the decode and then the execute stage of the pipeline. if the instruction is to be executed then cppass is driven high during the execute. if the coprocessor can execute the instruction immediately, it drives chsde[1:0] with last. if the instruction requires a wait cycle, then the coprocessor drives chsde[1:0] with wait and chsex[1:0] with last. figure 9.5 shows a cdp that is cancelled due to the previous instruction causing a data abort. the cdp instruction enters the execute stage of the pipeline and is signaled to execute when cppass is high. in the following phase, cplatecancel is asserted, which causes the coprocessor to terminate execution of the cdp instruction and to cause no state changes to the coprocessor. note in figure 9.5 that cplatecancel can be asserted during the memory cycle as well as during the execution cycle. the coprocessor should be able to handle instruction aborts during these two stages. wait wait last ignored cpclk ncpmreq cppass cplatecancel chsde[1:0] chsex[1:0] cpdout[31:0] mcr cpdin[31:0] mrc decode decode execute execute memory write go wait last processor pipeline interlock cop data cop data 9-8 external coprocessor interface rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 9.5 late cancelled cdp 9.3 privileged instructions the coprocessor can restrict certain instructions for use in privileged modes only. to do this, the coprocessor has to track the ncptrans output. figure 9.6 shows how ncptrans changes after a mode change. last cpclk ncpmreq cppass cplatecancel chsde[1:0] chsex[1:0] ignored execute memory exception exception (entry start) (continues) ldr with data abort decode execute processor pipeline stalling and interrupts 9-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 9.6 privileged instructions 9.4 stalling and interrupts figure 9.7 shows a stalled coprocessor instruction being abandoned due to an interrupt. the coprocessor can stall the processor during the execution of a coprocessor instruction if, for example, it is still busy with an earlier coprocessor instruction. to do so, the coprocessor associated with the decode stage instruction drives wait on chsde[1:0]. when the instruction concerned enters the execute stage of the pipeline, the coprocessor can drive wait onto chsex[1:0] for as many cycles as it wants in order to keep the instruction in the busy-wait loop. for interrupt latency reasons, the coprocessor can be interrupted while stalling, thus causing the instruction to be abandoned. abandoning execution is done through cppass. the coprocessor must monitor the state of cppass during every stall cycle. if it is high, the instruction should still be executed. if it is low, the instruction should be abandoned. note in figure 9.7 that cplatecancel is also asserted as a result of the execute interruption. ignored cpclk ncpmreq ncptrans cppass cplatecancel chsde[1:0] chsex[1:0] ignored last ignored old mode new mode execute execute execute memory (cycle 3) mode change (cycle 2) write decode decode decode execute processor pipeline memory write 9-10 external coprocessor interface rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 9.7 stalling and interrupts wait cpclk ncpmreq cppass cplatecancel chsde[1:0] chsex[1:0] wait wait wait ignored cpdout[31:0] mcr cpdin[31:0] mrc decode execute execute execute wait processor pipeline wait execute interrupted wait execute entry ARM966E-S microprocessor core technical manual 10-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 10 debug this chapter describes the operation of the ARM966E-S debug interface. the debug interface is based on ieee std 1149.1-1990. this chapter contains the following sections: ? section 10.1, ?ebug systems ? section 10.2, ?bout the debug interface ? section 10.3, ?can chain 15 ? section 10.4, ?reakpoints, watchpoints, and external debug requests ? section 10.5, ?rm9e-s clock domains ? section 10.6, ?etermining the core and system states ? section 10.7, ?bout the embeddedice-rt logic ? section 10.8, ?isabling the embeddedice-rt logic ? section 10.9, ?he debug communications channel ? section 10.10, ?eal-time debug a more detailed description of the arm9e-s debug features and jtag interface is provided in appendix d, debug in depth, of the arm9e-s technical reference manual. 10.1 debug systems the ARM966E-S forms one component of a debug system that interfaces from the high-level debugging you perform to the low-level interface the ARM966E-S supports. figure 10.1 shows a typical debug system. 10-2 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 10.1 typical debug system a debug system typically has three parts: ? the debug host ? the protocol converter ? debug target the debug host and the protocol converter are system-dependent. 10.1.1 the debug host the debug host is a computer that is running a software debugger, such as armsd . the debug host allows you to issue high-level commands, such as setting breakpoints or examining the contents of memory. 10.1.2 the protocol converter an interface, such as a parallel port, connects the debug host to the ARM966E-S development system. the messages broadcast over this connection must be converted to the interface signals of the ARM966E-S. the protocol converter performs this conversion. for example, multi-ice development system containing ARM966E-S host computer running arm or third party toolkit debug host protocol converter debug target debug systems 10-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.1.3 debug target the arm9e-s processor within the ARM966E-S has hardware extensions that ease debugging at the lowest level. the debug extensions allow you to: ? stall the core from program execution ? examine the core internal state ? examine the state of the memory system ? resume program execution. the major blocks of the arm9e-s debug model are described below and are shown in figure 10.2: figure 10.2 arm9e-s processor and debug logic arm9e-s processor core includes hardware support for debug. embeddedice-rt logic this set of registers and comparators is used to generate debug exceptions (such as breakpoints). this unit is described in section 10.7, ?bout the embeddedice-rt logic, page 10-14. tap controller controls the action of the scan chains using a jtag serial interface. arm9e-s embeddedice-rt arm9e-s tap controller arm9e-s scan chain 2 scan chain 1 processor 10-4 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. the arm9e-s debug model is extended within the ARM966E-S with the addition of scan chain 15. this scan chain is used for debug access to the cp15 register bank when bist is implemented. it allows the system state within the ARM966E-S to be con?ured while in the debug state, for instance, to enable or disable the sram before performing a debug load or store. the rest of this chapter describes the hardware debug extensions. 10.2 about the debug interface the ARM966E-S debug interface is based on ieee std. 1149.1-1990, standard test access port and boundary-scan architecture . refer to this standard for an explanation of the terms used in this chapter and for a description of the test access port (tap) controller states. the arm9e-s processor core contains hardware extensions for advanced debugging features, which make it easier to develop the hardware, application software, and operating systems. the debug extensions allow you to force the core into the debug state . in the debug state, the arm9e-s processor and ARM966E-S memory system are effectively stopped and isolated from the rest of the system in halt mode . from this mode, you can examine the internal state of the arm9e-s processor, the ARM966E-S system, and the external state of the ahb while all other system activity continues as normal. when debug is complete, the arm9e-s processor restores the core and system state, and resumes program execution. in addition, the arm9e-s supports a real-time debug mode called monitor mode , where instead of generating a breakpoint or watchpoint, an internal instruction abort or data abort is generated. when monitor mode is used in conjunction with a debug monitor program that is activated by the abort exception entry, you can debug the ARM966E-S while allowing the execution of critical interrupt service routines. the debug monitor program typically communicates with the debug host over the ARM966E-S debug communication channel. monitor mode debug is described in section 10.10, ?eal-time debug, page 10-20. about the debug interface 10-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.2.1 stages of debug a request on one of the external debug interface signals or on an internal functional unit known as the embeddedice-rt logic forces the arm9e-s processor into the debug state. the interrupts that activate debug are: ? a breakpoint (a given instruction fetch) ? a watchpoint (a data access) ? an external debug request the internal state of the arm9e-s processor is examined using a jtag-style serial interface, allowing instructions to be serially inserted into the pipeline without using the external data bus. for example, when in the debug state, a store multiple instruction (stm) can be inserted into the instruction pipeline, which exports the contents of the ARM966E-S registers. this data can be serially shifted out without affecting the rest of the system. 10.2.2 clocks the system and test clocks must be synchronized externally to the ARM966E-S macrocell. the arm multi-ice debug agent directly supports one or more cores within an asic design. to synchronize off-chip debug clocking with the ARM966E-S macrocell requires a three-stage synchronizer. the off-chip device (for example, multi-ice) issues a tck signal, and then waits for the rtck (returned tck) signal to come back. synchronization is maintained because the off-chip device does not progress to the next tck until after rtck is received. figure 10.3 shows this synchronization logic. 10-6 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 10.3 clock synchronization logic 10.3 scan chain 15 scan chain 15 (sc15) provides debug access to the cp15 register bank, allowing the system state within the ARM966E-S to be con?ured while in the debug state. table 10.1 shows the order of sc15 from the dbgtdi input to the dbgtdo output. dbgtms dbgtdi multiice interface pads dbgntrst dbgtdo dbgtcken tdo rtck tck clk tms dq tck synchronizer dq dq clk clk clk ARM966E-S input sample and hold tdi dq dq table 10.1 scan chain 15 addressing mode bit order bits contents 38 read = 0, write = 1 37:32 cp15 register address 31:0 cp15 register value scan chain 15 10-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. table 10.2 shows the cp15 register address ?ld of sc15, which provides debug access to the cp15 registers. the scan address decode supersedes the existing functional decode logic that is used to access the cp15 registers during mcr and mrc instructions (see section 3.7.2, ?p15 registers, page 3-9). the decode overload is performed as the follows: sc15 only allows access to bit 0 of the opcode2 ?ld by default. to allow access to the address and general bist registers within cp15 table 10.2 mapping of scan chain 15 address field to cp15 registers bit 38 bits[37:32] bits[31:30] cp15 reg number meaning 0 0 0000 0 xx c0 read id register 0 0 0001 0 xx c1 read control register 1 0 0001 0 xx c1 write control register 0 1 1111 1 00 c15 read bist control register 1 1 1111 1 00 c15 write bist control register 0 1 1111 0 01 c15 read ibist address 1 1 1111 0 01 c15 write ibist address 0 1 1111 1 01 c15 read ibist general 1 1 1111 1 01 c15 write ibist general 0 1 1111 0 11 c15 read dbist address 1 1 1111 0 11 c15 write dbist address 0 1 1111 1 11 c15 read dbist general 1 1 1111 1 11 c15 write dbist general bit 37 corresponds to opcode 1 of an mcr or mrc instruction. bits [36:33] correspond to the crn ?ld of an mcr or mrc instruction. bit 32 corresponds to bit 0 of the opcode 2 ?ld of an mcr or mrc instruction. bits [2:1] bits [2:1] of opcode 2 are tied to 00 during the debug state. 10-8 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. register 15, bits [31:30] of sc15 are overloaded as shown in table 10.2. there are certain restrictions with the overloading. when writing to the bist general registers (writing a new seed), bits[31:30] of the seed are restricted to those values shown in table 10.2. these bits are not used in the bist address registers; so there are no debug restrictions when accessing these registers. the ability to control the ARM966E-S system state through scan chain 15 provides extra debug visibility. for example, if the debugger wishes to compare the contents of an address that maps to the i-sram or d-sram with the same address in external memory, the debugger can: 1. load from the address with the sram enabled to return the sram data. 2. disable the sram. 3. perform the load again. the second load now accesses the ahb because the sram is disabled, returning the value from ahb memory. 10.4 breakpoints, watchpoints, and external debug requests the ARM966E-S enters the debug state when a breakpoint, watchpoint, or external debug request occurs. there are four primary external signals associated with the debug interface: ? dbgiebkpt, dbgdewpt, and edbgrq are system requests for the ARM966E-S core to enter the debug state. ? the dbgack signal informs the system that the ARM966E-S is in the debug state. several ?ures in the following subsections illustrate ARM966E-S waveforms in the debug state. table 10.3 de?es the notations used in these ?ures. breakpoints, watchpoints, and external debug requests 10-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.4.1 entry into debug state on breakpoint any instruction being fetched from memory is sampled at the end of a cycle. to apply a breakpoint to that instruction, the breakpoint signal must be asserted by the end of the same cycle as shown in figure 10.4. you can build external logic, such as additional breakpoint comparators, to extend the breakpoint functionality of the embeddedice-rt logic. these outputs must be applied to the dbgiebkpt input. this signal is ored with the internally generated breakpoint signal before being applied to the arm9e-s core control logic. the timing of the input makes it unlikely that data-dependent external breakpoints are possible. a breakpointed instruction is allowed to enter the execute stage of the pipeline, but any state change as a result of the instruction is prevented. all writes from previous instructions complete as usual. the decode cycle of the debug entry sequence occurs during the execute cycle of the breakpointed instruction. the latched breakpoint signal forces the processor to start the debug sequence. figure 10.4 shows the breakpoint timing. table 10.3 debug state figure notations term de?ition fx, dx, ex, mx, wx fetch, decode, execute, memory, and writeback stages for instruction x on instr[31:0] ddebug decode debug entry edebug1, edebug2 execute debug entry ldr load register from memory instruction dp data processing instruction b branch instruction t trigger instruction 10-10 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 10.4 breakpoint timing 10.4.2 breakpoints and exceptions a breakpointed instruction can have a prefetch abort associated with it. if so, the prefetch abort takes priority and the breakpoint is ignored. (if there is a prefetch abort, instruction data might be invalid, the breakpoint might be data-dependent, and if the data is incorrect, the breakpoint could have triggered incorrectly.) swi and unde?ed instructions are treated the same as any other instruction with a breakpoint set on it. therefore the breakpoint takes priority over the swi or unde?ed instruction. on an instruction boundary, if there is a breakpointed instruction and an interrupt (nirq or nfiq), the interrupt is taken and the breakpointed instruction is discarded. when the interrupt is being serviced, the execution ?w is returned to the original program. thus the instruction that was previously breakpointed is fetched again, and if the breakpoint is still set, the processor enters the debug state when it reaches the execute stage of the pipeline. when the processor enters the halt-mode debug state, it is important that further interrupts do not affect the instructions executed. for this reason, as soon as the processor enters the stop-mode debug state, interrupts are disabled, although the state of the i and f bits in the program status register (psr) are not affected. f1 d1 f2 e1 d2 f1 m1 e2 d1 ddebug w1 m2 e1 edebug1 w2 m1 edebug2 w1 2 13 4 clk ia[31:1] instr[31:0] dbgiebkpt dbgack breakpoints, watchpoints, and external debug requests 10-11 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.4.3 watchpoints entry into the debug state following a watchpointed memory access is imprecise because of the nature of the pipeline. external logic, such as external watchpoint comparators, can be built to extend the functionality of the embeddedice-rt logic. their outputs must be applied to the dbgdewpt input. this signal is simply ored with the internally generated watchpoint signal before being applied to the arm9e-s core control logic. the timing of the input makes it unlikely that data-dependent external watchpoints are possible. after a watchpointed access, the next instruction in the processor pipeline is always allowed to complete execution. where this instruction is a single-cycle data-processing instruction, entry into the debug state is delayed for one cycle while the instruction completes. the timing of debug entry following a watchpointed load in this case is shown in figure 10.5. figure 10.5 watchpoint entry with data processing instruction f1 d1 f2 e1 d2 fldr m1 e2 dldr fdp w1 m2 eldr ddp f5 w2 mldr edp d5 wldr mdp e5 w5 ddebug wdp m5 edebug1edebug2 clk inmreq instr[31:0] da[31:0] wdata[31:0] rdata[31:0] dbgdewpt dbgack 12 dp56 78 ldr 10-12 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. although instruction 5 enters the execute stage, it is not executed, and there is no state update as a result of this instruction. when the debugging session is complete, normal continuation involves a return to instruction 5, the next instruction in the code sequence to be executed. the instruction following the instruction that generated the watchpoint might have modi?d the program counter (pc). so it is not possible to determine the instruction that caused the watchpoint. a timing diagram in figure 10.6 shows debug entry after a watchpoint where the next instruction is a branch. however, it is always possible to restart the processor. figure 10.6 watchpoint entry with branch when the processor enters the debug state, the arm9e-s core is interrogated to determine its state. in the case of a watchpoint, the pc contains a value that is ?e instructions after the address of the next instruction to be executed. therefore if on entry to the debug state in arm state, the instruction sub pc, pc, #20 is scanned in and the processor restarted, execution ?w returns to the next instruction in the code sequence. fldr dldr fb eldr db mldr eb wldr mb ft wb dt et ddebug edebug1edebug2 clk inmreq instr[31:0] da[31:0] wdata[31:0] rdata[31:0] dbgdewpt dbgack b t ldr x x t+4 t+8 ia[31:1] t+c breakpoints, watchpoints, and external debug requests 10-13 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.4.4 watchpoints and exceptions if there is an abort with the data access as well as a watchpoint, the watchpoint condition is latched, the exception entry sequence performed, and then the processor enters the debug state. if there is an interrupt pending, the arm9e-s core allows the exception entry sequence to occur and then enters the debug state. 10.4.5 debug request a debug request can take place through the embeddedice-rt logic or through assertion of the edbgrq signal. the request is synchronized and passed to the processor. a debug request takes priority over any pending interrupt. following synchronization, the core enters the debug state when the instruction at the execute stage of the pipeline is completed (when memory and write stages of the pipeline have completed). while waiting for the instruction to ?ish executing, no more instructions are issued to the execute stage of the pipeline. caution: asserting edbgrq in monitor mode results in unpredictable behavior. 10.4.6 actions of the arm9e-s core in debug state when the arm9e-s core is in the debug state, both memory interfaces indicate internal cycles, which ensures that both the tightly coupled sram within the ARM966E-S and the ahb interface are quiescent. the rest of the ahb system can thus ignore the arm9e-s processor core and function as normal. because the rest of the system continues operation, the arm9e-s processor core ignores aborts and interrupts. the nreset signal must be held stable during debug. if the system applies a reset to the ARM966E-S (nreset is driven low), the arm9e-s processor changes state without the knowledge of the debugger. 10-14 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.5 arm9e-s clock domains the arm9e-s clock, clk, is quali?d by two clock enables: ? sysclken controls access to the memory system ? dbgtcken controls debug operations during normal operation, sysclken conditions clk to clock the core. when the ARM966E-S is in the debug state, dbgtcken conditions clk to clock the core. 10.6 determining the core and system states when the ARM966E-S is in the debug state, you can examine the core and system state by forcing the load and store multiples into the instruction pipeline. before you can examine the core and system state, the debugger must determine whether the processor entered debug from thumb state or arm state, by examining bit 4 of the embeddedice-rt debug status register. when bit 4 is high, the core enters debug from thumb state. 10.7 about the embeddedice-rt logic the arm9e-s embeddedice-rt logic provides integrated on-chip debug support for the arm9e-s processor core. embeddedice-rt is programmed serially using the arm9e-s tap controller. figure 10.7 illustrates the relationship between the core, embeddedice-rt, and the tap controller, showing only the signals that are pertinent to embeddedice-rt. about the embeddedice-rt logic 10-15 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. figure 10.7 the arm9e-s, tap controller, and embeddedice-rt the embeddedice-rt logic comprises: ? two real-time watchpoint units ? two independent registers: the debug control register and the debug status register ? debug communications channel. the debug control register and the debug status register provide overall control of embeddedice-rt operation. you can program one or both watchpoint units to halt the execution of instructions by the core. execution halts when the values programmed into the embeddedice-rt match the values currently appearing on the address bus, data bus, and various control signals. any bit can be masked so that its value does not affect the comparison. dbgext[1:0] dbgcommrx dbgcommtx dbgrng[1:0] dbgack dbgiebkpt edbgrq dbgdewpt dbgen dbgtcken dbgtms dbgtdi dbgtdo clk embeddedice-rt processor dbgntrst ta p 10-16 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. each watchpoint unit can be con?ured to be either a watchpoint (monitoring data accesses) or a breakpoint (monitoring instruction fetches). watchpoints and breakpoints can be data-dependent. 10.8 disabling the embeddedice-rt logic to disable the embeddedice-rt logic, force the dbgen input low. hardwiring dbgen low permanently disables debug access. when dbgen is low, it inhibits dbgdewpt, dbgiebkpt, and edbgrq to the arm9e-s, and dbgack from the ARM966E-S is always low. 10.9 the debug communications channel the embeddedice-rt logic contains a communications channel for passing information between the target and the host debugger. this channel is implemented as coprocessor 14 (cp14). the communications channel comprises: ? a 32-bit communications data read register ? a 32-bit communications data write register ? a 6-bit communications control register for synchronized handshaking between the processor and the asynchronous debugger. these registers are located in ?ed locations in the embeddedice-rt logic register map and are accessed from the processor using mcr and mrc instructions to cp14. in addition to the communications channel registers, the processor can access a one-bit debug status register for use in the real-time debug con?uration. the debug communications channel 10-17 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.9.1 debug communication channel registers cp14 contains four registers. table 10.4 shows the register allocations in cp14. 10.9.2 debug communications channel status register the debug communications channel status register is read-only. it controls synchronized handshaking between the processor and the debugger. the debug communications channel status register is shown in figure 10.8. figure 10.8 debug communications channel status register version version [31:28] this ?ld contains a xed pattern that denotes the embeddedice-rt version number (in this case 0b0011). res reserved [27:2] these bits are reserved and read as zeros. w write available 1 this bit indicates whether the communications data write register is available (from the viewpoint of the processor). if, from the viewpoint of the processor, the communications data write register is free (w = 0), new data can be written. if the register is not free (w = 1), the processor must poll until w = 0. from the viewpoint of the debugger, when w = 1, new data is written that can be scanned out. table 10.4 cp14 register map register name register number notes communications channel status c0 read only communications channel data read c1 for reads communications channel data write c1 for writes communications channel monitor mode debug status c2 read/write 31 28 27 210 version res w r 10-18 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. r read available 0 this bit indicates whether there is new data in the communications data read register. from the viewpoint of the processor, if r = 1, there is new data that can be read using an mrc instruction. from the viewpoint of the debugger, if r = 0, the communications data read register is free, and new data can be placed there through the scan chain. if r = 1, data previously placed there through the scan chain is not collected by the processor, and so the debugger must wait. from the viewpoint of the debugger, the registers are accessed using the scan chain in the usual way. from the viewpoint of the processor, these registers are accessed using coprocessor register transfer instructions. you must use the following instructions: because the thumb instruction set does not contain coprocessor instructions, you are advised to access this data using swi instructions when in thumb state. 10.9.3 communications channel monitor mode debug status register the cp14 debug status register is provided for a debug monitor when the arm9e-s processor is con?ured into monitor mode. the cp14 debug status register is a one-bit wide read/write register as shown in figure 10.9. figure 10.9 coprocessor 14 debug status register format bit 0, the dbgabt bit, indicates whether the processor took a prefetch (dbgabt = 1) or data abort (dbgabt = 0) in the past because of a mrc p14, 0, rd, c0, c0 returns the debug communications control register into rd. mcr p14, 0, rn, c1, c0 writes the value in rn to the communications data write register. mrc p14, 0, rd, c1, c0 returns the debug data read register into rd. 31 10 res dbg abt the debug communications channel 10-19 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. breakpoint or watchpoint. if the ARM966E-S takes a prefetch abort as a result of a breakpoint or watchpoint, then the bit is set. if on a particular instruction or data fetch, both the debug abort and external abort signals are asserted, the external abort takes priority and the dbgabt bit is not set. you can read or write the dbgabt bit by means of mrc or mcr instructions. this bit can be used by a real-time debug aware abort handler. this handler examines the dbgabt bit to determine whether the abort is externally or internally generated. if the dbgabt bit is set, the abort handler initiates communication with the debugger over the communications channel. 10.9.4 using the communications channel messages can be sent and received using the communications channel. 10.9.4.1 sending a message to the debugger when the processor wishes to send a message to the debugger, it must check to see if the communications data write register is free for use. the processor reads the debug communications control register to check the status of the w bit. ? if w bit is cleared, the communications data write register is free for use. ? if the w bit is set, previously written data is not read by the debugger. the processor must continue to poll the debug communications control register until the w bit is cleared. when the w bit is cleared, a message is written by a register transfer to coprocessor 14. because the data transfer occurs from the processor to the communications data write register, the w bit is set in the debug communications control register. the debugger sees both the r and w bits when it polls the debug communications control register through the jtag interface. when the debugger sees that the w bit is set, it can read the communications data write register, and scan the data out. the action of reading this data register clears the w bit in the debug communications control register. at this point, the communications process can begin again. 10-20 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. 10.9.4.2 receiving a message from the debugger transferring a message from the debugger to the processor is similar to sending a message to the debugger. in this case, the debugger polls the r bit of the debug communications control register: ? if the r bit is cleared, the communications data read register is free for use, and data can be placed there for the processor to read ? if the r bit is set, previously deposited data is not yet collected, so the debugger must wait. when the communications data read register is free, data is written there using the jtag interface. the action of this write sets the r bit in the debug communications control register. the processor polls the debug communications control register. if the r bit is set, there is data that can be read using an mrc instruction to cp14. the action of this load clears the r bit in the debug communications control register. when the debugger polls this register and sees that the r bit is cleared, the data is taken, and the process can be repeated. 10.10 real-time debug the arm9e-s processor within the ARM966E-S contains logic that allows the debugging of a system without stopping the core entirely. thus critical interrupt routines can still be serviced while the core is being interrogated by the debugger. setting bit 4 of the debug control register enables the real-time debug features of the arm9e-s. when bit 4 is set, the embeddedice-rt logic is con?ured so that a breakpoint or watchpoint causes the ARM966E-S to enter abort mode, taking the prefetch abort or data abort vectors, respectively. when the arm966e- s is con?ured for real-time debugging, you must be aware of the following restrictions: ? breakpoints or watchpoints might not be data-dependent. no support is provided for use of the range and chain functionalities. breakpoints or watchpoints can only be based on: instruction or data addresses external watchpoint conditioner (dbgextern) real-time debug 10-21 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. user or privileged mode access (dntrans and intrans) read or write access (watchpoints) access size (breakpoints, itbit, and watchpoints, dmas[1:0]). ? the single-step hardware is not enabled. ? external breakpoints and watchpoints are not supported. ? the vector-catching hardware can be used but must not be con?ured to catch the prefetch or data abort exceptions. caution: no support is provided to mix halt mode and monitor mode debug functionalities. when the core is con?ured into the monitor mode, asserting the external edbgrq signal results in unpredictable behavior. setting the internal edbgrq bit results in unpredictable behavior. when an abort is generated by the monitor mode it is recorded in the debug status register in cp14 (see section 10.9.3, ?ommunications channel monitor mode debug status register?. because the monitor mode debug does not put the arm9e-s into the debug state, it is necessary to change the contents of the watchpoint registers while external memory accesses are taking place rather than changing them when in the debug state. if the watchpoint registers are written to during an access, all matches from the affected watchpoint unit using the register being updated are disabled for the cycle of the update. if there is a possibility of false matches occurring during changes to the watchpoint registers, caused by old data in some registers and new data in others, then you must: 1. disable that watchpoint unit using the control register for that watchpoint unit. 2. change the other registers. 3. re-enable the watchpoint unit by rewriting the control register. 10-22 debug rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. ARM966E-S microprocessor core technical manual 11-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. chapter 11 test methodology this chapter describes the ARM966E-S test methodology. full-scan atpg and rambist are provided to achieve >99% stuck at faults and ram data sensitivity faults. this chapter includes the following sections: ? section 11.1, ?can insertion ? section 11.2, ?ambist for additional information, please contact your lsi logic applications engineer. 11.1 scan insertion scan insertion ensures a high level of fault coverage using automatic test pattern generation (atpg) tools and compatible synthesis library cells. it has an impact on the area and performance of a design. it also imposes constraints on the use of clock gating within the hdl code. 11.2 rambist lsi logic does not implement arm s ARM966E-S rambist controller. check with your lsi logic applications engineer on how to add rambist to your design. 11-2 test methodology rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. ARM966E-S microprocessor core technical manual a-1 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. appendix a arm9e-s enhanced instructions this appendix describes the instruction enhancements made to the arm9e-s instruction set. the extensions have been developed to improve the arm architecture s performance in signal processing algorithms. many real-time applications require both the bene?s of a microcontroller and a dsp. microcontrollers bring high-level language support with solid development tools, low cost memory systems, low interrupt latency, and fast context switching time; dsps tend to have features for fast math performance in real-time control tasks. real-time applications are typically those involving devices that move, including hard disk drives, printers, engine controllers, and general-purpose servos such as those found in automotive steering control. however, applications such as voice processing and modems also bene? greatly from a controller with the mix of both microcontroller and dsp functionalities. it is for these reasons that recent microcontroller architectures have featured both controller and dsp functionality. the arm9e-s core features an enhanced 32 x 16 hardware multiplier, which increases the arm s performance in hard real-time signal processing applications. the extensions consist of: ? new multiply instructions that allow the ef?ient use of data bandwidth so that best use can be made of the new multiplier. ? new saturation extensions to existing math instructions for use in the design of stable control loops and bit-exact algorithms. a-2 arm9e-s enhanced instructions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. in each of the instruction de?itions, the following abbreviations are used: note also that in the instruction de?itions, the term unpredictable means the result of an instruction cannot be relied upon. unpredictable instructions or results must not represent security holes. unpredictable instructions must not halt or hang the processor, or any parts of the system. {cond} two character conditional execution mnemonic. refer to the arm architecture reference manual for a complete listing of condition codes. rd,rs,rn,rm denote arm register numbers. x/y denotes use of either the high or low half of an arm register as a source operand. ? is used to denote the top (most signi?ant), and ? denotes the bottom (least signi?ant) halfword. sbz a ?ld in the instruction opcode that should be written as zero. nonzero values produce unpredictable results. signextend(a) sign-extends (propagates the sign bit) its argument to 32 bits. sat(f) saturates the result of f to 32 bits. if f over?ws 32 bits and is negative, then sat( f ) returns the maximum negative value that can be represented in 32 bits (0x80000000). if f over ows 32 bits and is positive, sat( f ) returns 0x7fffffff. doessat(f) returns 1 if f would saturate when truncated to 32 bits, otherwise returns 0. a-3 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. clz count leading zeros format clz{cond} rd, rm description this operation returns the number of leading zeros in the register rm into the destination register rd. this operation was originally de?ed as part of the armv5t instruction set extensions. it is mentioned here because clz is supported in an arm9e-compatible processor regardless of whether that processor also supports the full armv5 instruction set. used for speeding up the normalization at the start of a newton-raphson based division and normalization of ?ed-point numbers. operation if (rm == 0) rd = 32 else for (i = 31; i >= 0; i--) { if (rm[i] == 1) then rd = 31 ?i break } exceptions none quali?rs condition code notes writing to r15: specifying r15 (pc) for register rd or rm is unpredictable. 31 28272625242322212019 1615 1211 876543 0 cond 00010110 sbz rd sbz 0001 rm a-4 arm9e-s enhanced instructions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. qadd saturating add format qadd{cond} rd, rm, rn description this instruction saturates the sum of rm and rn and stores the result in rd. there are no immediate or shifted variants of this instruction. this operation affects the sticky-over?w bit ? due to over?w in addition. operation rd[31:0] = sat(rm[31:0] + rn[31:0]) if (doessat(rm[31:0] + rn[31:0])) s flag = 1 exceptions none quali?rs condition code notes writing to r15: specifying r15 (pc) for register rd, rn, or rm is unpredictable. assembler mnemonic: this mnemonic has reversed operands to be consistent with the qdsub mnemonic. 31 28272625242322212019 1615 1211 876543 0 cond 00010000 rn rd sbz 0101 rm a-5 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. qdadd saturated double rn and saturated add format qdadd{cond} rd, rm, rn description double rn and saturate, then add to rm and saturate. the result is stored in rd. there are no immediate or shifted variants of this instruction. this operation affects the sticky-over?w bit ? due to over?w in either the double operation or the addition. operation rd[31:0] = sat(rm[31:0] + sat(rn[31:0] *2)) if (doessat(rn[31:0]*2) || doessat(rm[31:0] + sat(rn[31:0]*2))) s flag = 1 exceptions none quali?rs condition code notes writing to r15: specifying r15 (pc) for register rd, rm, or rn is unpredictable. assembler mnemonic: this mnemonic has reversed operands to be consistent with the qdsub mnemonic. 31 28272625242322212019 1615 1211 876543 0 cond 00010100 rn rd sbz 0101 rm a-6 arm9e-s enhanced instructions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. qdsub saturated double rn and saturated subtract format qdsub{cond} rd, rm, rn description double rn and saturate, then subtract from rm and saturate. the result is stored in rd. there are no immediate or shifted variants of this instruction. this operation affects the sticky-over?w bit ? due to over?w in either the double operation or the subtraction. operation rd[31:0] = sat(rm[31:0] ?sat(rn[31:0]*2)) if (doessat(rn[31:0]*2) || doessat(rm[31:0] sat(rn[31:0]*2))) s flag = 1 exceptions none quali?rs condition code notes writing to r15: specifying r15 (pc) for register rd, rm or rn is unpredictable. assembler mnemonic: this operation performs a reverse subtract (when compared to the normal arm sub operation). the operands in the assembler mnemonic have been reversed so that the mnemonic can be qdsub instead of qdrsb. 31 28272625242322212019 1615 1211 876543 0 cond 00010110 rn rd sbz 0101 rm a-7 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. qsub saturating subtract format qsub{cond} rd, rm, rn description subtract rn from rm and saturate. the result is stored in rd. there are no immediate or shifted variants of this instruction. this operation affects the sticky-over?w bit ? due to over?w in the subtraction. operation rd[31:0] = sat(rm[31:0] - rn[31:0]) if (doessat(rm[31:0] ?rn[31:0])) s flag = 1 exceptions none quali?rs condition code notes writing to r15: specifying r15 (pc) for register rd, rm or rn is unpredictable. assembler mnemonic: this mnemonic has reversed operands to be consistent with the qdsub mnemonic. 31 28272625242322212019 1615 1211 876543 0 cond 00010010 rn rd sbz 0101 rm a-8 arm9e-s enhanced instructions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. smlaxy signed integer multiply-accumulate format smlaxy {cond} rd, rm, rs, rn description the signed integer multiply-accumulate operation performs the multiply on two 16-bit source operands from half of register rm and half of rs, producing a 32-bit product and then a 32-bit accumulation with rn. this operation affects the sticky-over?w bit ? due to over?w in the accumulation. operation if (bit[5] == 0) a-9 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. smlalxy signed multiply-accumulate format smlalxy{cond} rdlo, rdhi, rm, rs description the signed multiply-accumulate operation performs a multiply on two 16-bit source operands from half of register rm and half of rs. then a 64-bit accumulate is done with rdlo and rdhi. operation if (bit[5] == 0) a-10 arm9e-s enhanced instructions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. smlawy signed integer multiply-accumulate format smlawy{cond} rd, rm, rs, rn description the signed integer multiply-accumulate operation performs a 32 x 16 bit multiply on the 32-bit operand in rm and the 16-bit source operand from half of register rs. a 32-bit accumulate of the upper 32 bits of the 48-bit product is done with rn. this operation affects the sticky-over?w bit ? due to over?w in the accumulation. operation if (bit[6] == 0) a-11 rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. smulxy signed integer multiply format smulxy{cond} rd, rm, rs description the signed integer multiply operation performs the multiply on two 16-bit source operands from half of register rm and half of rs, producing a 32-bit result in rd. operation if (bit[5] == 0) a-12 arm9e-s enhanced instructions rev. a copyright 1999-2001 by lsi logic corporation. all rights reserved. smulwy signed integer multiply format smulwy{cond} rd, rm, rs description the signed integer multiply operation performs a 32 x 16 bit multiply on the 32-bit operand in rm and the 16-bit source operand from half of register rs, taking the upper 32 bits of the 48-bit product. operation if (bit[6] == 0) ARM966E-S microprocessor core technical manual ix-1 rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. index a address decoders 1-4 advanced high-performance bus (ahb) 1-4 interface unit 5-1 ahb 1-4 clocking 5-11 interface signals 2-3 interface unit 5-1 operation 5-11 ARM966E-S block diagram 1-3 arm9e-s processor core 1-3 atpg 11-1 scan control signals 2-21 automatic test pattern generation 11-1 b base restored data abort model 3-2 base updated data abort model 3-2 basic transfers 5-12 bist control register 3-15 block diagram ARM966E-S 1-3 breakpoints 10-9 , 10-16 exceptions 10-10 instruction boundary 10-10 prefetch abort 10-10 timing 10-10 burst operation example 5-15 burst operations 5-15 burst signal encoding 5-5 burst types 5-4 busy transfers 5-3 c cdp instructions 9-7 clk 10-14 clock system 10-5 test 10-5 control register 3-10 coprocessor instruction format 3-4 coprocessor instructions 9-2 coprocessor interface signals 2-8 core control register 3-12 core state, determining 10-14 count leading zeros a-3 cp14 3-1 cp15 3-1 data bist fail address register 3-18 data bist fail/pause read data register 3-19 data bist start/pause address register 3-18 data bist test/pause write data register 3-18 instruction bist fail address register 3-17 instruction bist fail/pause read data register 3-17 instruction bist test/pause write data register 3-17 instruction format 3-4 rambist register map 3-14 cpu register organization 3-6 d data abort exception 4-6 data access memory abort exception 4-6 data ram 8-1 data ram signals 2-10 dbgack 10-8 , 10-16 dbgdewpt 10-16 dbgen 10-16 dbgiebkpr 10-16 dbgtcken 10-14 ix-2 index rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. debug communcations data read register 10-16 communications channel 10-16 , 10-19 communications channel status register 10-17 communications control register 10-16 communications data write register 10-16 control register 10-15 extensions 10-4 hardware extensions 10-3 host 10-2 interface signals 10-5 , 10-8 message transfer 10-19 multiice 10-5 real-time 10-20 request 10-13 signals 2-14 state 10-5 actions of arm9e-s 10-13 breakpoints 10-9 watchpoints 10-11 status register 10-15 , 10-18 support 10-14 systems 10-1 target 10-3 disabling embeddedice-rt 10-16 dma signals 2-12 e early burst termination 5-15 edbgrq 10-16 embeddedice-rt 10-3 , 10-13 debug communications channel 10-16 debug status register 10-14 disabling 10-16 macrocell 10-14 operation 10-15 overview 10-14 error response 5-18 etm interface signals 2-16 exception data abort 4-6 data access memory abort 4-6 fast interrupt request 4-7 fiq 4-7 flow 4-2 handling 4-1 instruction fetch memory abort 4-5 interrupt request 4-7 irq 4-7 prefetch abort 4-5 priority order 4-2 processing modes 4-2 reset 4-4 software interrupt 4-5 undefined instruction 4-4 external coprocessor interface 9-1 f fiq (fast interrupt request) exception 4-7 h hrdata[31:0] 5-10 hwdata[31:0] 5-8 i id code register 3-10 idle transfers 5-3 initialization control signals 2-21 instruction bist start/pause address register 3- 16 instruction enhancements a-1 instruction fetch memory abort exception 4-5 instruction format 3-4 instruction ram 8-1 instruction ram signals 2-10 interlocked mcr 9-6 irq (interrupt request) exception 4-7 j jtag interface 10-3 , 10-5 l ldc/stc cycle timing 9-3 ldc/stc instructions 9-2 m mcr/mrc cycle timing 9-6 mcr/mrc instructions 9-5 memory map 3-5 miscellaneous signals 2-20 multiice 10-5 multiple transfers 5-14 multiplexer interconnection 5-2 index ix-3 rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. n nonrecoverable error 6-3 nonsequential transfers 5-3 p prefetch abort exception 4-5 privileged instructions 9-8 privileged mode 3-3 processor core 1-3 processor modes 3-3 protection signal encoding 5-7 protocol converter 10-2 r read-lock-write 6-3 registers bist control 3-15 control 3-10 core control 3-12 cp15 data bist fail address 3-18 cp15 data bist fail/pause read data 3-19 cp15 data bist start/pause address 3-18 cp15 data bist test/pause write data 3-18 cp15 instruction bist fail address 3-17 cp15 instruction bist fail/pause read data 3- 17 cp15 insturction bist test/pause write data 3- 17 debug communications channel status 10-17 debug communications control 10-16 debug communications data read 10-16 debug communications data write 10-16 debug control 10-15 debug status 10-15 , 10-18 embeddedice-rt debug status 10-14 id code 3-10 instruction bist start/pause address 3-16 trace process identifier 3-13 reset exception 4-4 retry response 5-19 rtck 10-5 s saturated double rn and saturated add a-5 saturated double rn and saturated subtract a-6 saturating add a-4 saturating subtract a-7 scan insertion 11-1 serial interface, jtag 10-3 , 10-5 signal types debug interface 10-5 , 10-8 signals ahb interface 2-3 atpg scan control signals 2-21 clk 10-14 coprocessor interface 2-8 data ram 2-10 dbgack 10-8 , 10-16 dbgdewpt 10-16 dbgen 10-16 dbgiebkpt 10-16 dbgtcken 10-14 debug 2-14 dma 2-12 edbgrq 10-16 etm interface 2-16 initialization control 2-21 instruction ram 2-10 miscellaneous 2-20 rtck 10-5 sysclken 10-14 tck 10-5 signed integer multiply a-11 , a-12 signed integer multiply-accumulate a-8 , a-10 signed multiply-accumulate a-9 simple transfer 5-13 single transfers 5-5 size encoding 5-6 slave transfer responses 5-16 software interrupt exception 4-5 split response 5-19 sram enabling 8-2 interfaces 8-6 requirements 8-1 wrapper 8-5 stalling and interrupts 9-9 state, debug 10-5 states, tap controller 10-4 supported data types 3-2 sysclken 10-14 system controller 7-1 system state, determining 10-14 ix-4 index rev. a copyright 1999?001 by lsi logic corporation. all rights reserved. t tap controller 10-3 , 10-14 states 10-4 tck 10-5 test access port 10-4 test clock 10-5 test methodology 11-1 trace process identifier register 3-13 transfer type encoding 5-3 transfer type examples 5-4 transfer with wait states 5-14 two-cycle response 5-17 u unbuffered writes 6-3 undefined instruction exception 4-4 user mode 3-3 w watchpoints 10-11 , 10-15 , 10-16 exceptions 10-13 timing 10-11 write buffer 6-1 write buffer flush 6-2 write buffer full 6-2 write buffer operation 6-2 ARM966E-S microprocessor core technical manual rev. a copyright 2000?001 by lsi logic corporation. all rights reserved. customer feedback we would appreciate your feedback on this document. please copy the following page, add your comments, and fax it to us at the number shown. if appropriate, please also fax copies of any marked-up pages from this document. impor tant: please include your name, phone number, fax number, and company address so that we may contact you directly for clari?ation or additional information. thank you for your help in improving the quality of our documents. customer feedback rev. a copyright 2000?001 by lsi logic corporation. all rights reserved. reader s comments fax your comments to: lsi logic corporation technical publications m/s e-198 fax: 408.433.4333 please tell us how you rate this document: ARM966E-S microprocessor core technical manual. place a check mark in the appropriate blank for each category. what could we do to improve this document? if you found errors in this document, please specify the error and page number. if appropriate, please fax a marked-up copy of the page(s). please complete the information below so that we may contact you directly for clari?ation or additional information. excellent good average fair poor completeness of information ____ ____ ____ ____ ____ clarity of information ____ ____ ____ ____ ____ ease of ?ding information ____ ____ ____ ____ ____ technical content ____ ____ ____ ____ ____ usefulness of examples and illustrations ____ ____ ____ ____ ____ overall manual ____ ____ ____ ____ ____ name date telephone title company name street city, state, zip department mail stop fax customer feedback rev. a copyright 2000?001 by lsi logic corporation. all rights reserved. customer feedback rev. a copyright 2000?001 by lsi logic corporation. all rights reserved. u.s. distributors by state a. e. avnet electronics http://www.hh.avnet.com b. m. bell microproducts, inc. (for hab s) http://www.bellmicro.com i. e. insight electronics http://www.insight-electronics.com w. e. wyle electronics http://www.wyle.com alabama daphne i. e. tel: 334.626.6190 huntsville a. e. tel: 256.837.8700 b. m. tel: 256.705.3559 i. e. tel: 256.830.1222 w. e. tel: 800.964.9953 alaska a. e. tel: 800.332.8638 arizona phoenix a. e. tel: 480.736.7000 b. m. tel: 602.267.9551 w. e. tel: 800.528.4040 tempe i. e. tel: 480.829.1800 tucson a. e. tel: 520.742.0515 arkansas w. e. tel: 972.235.9953 california agoura hills b. m. tel: 818.865.0266 granite bay b. m. tel: 916.523.7047 irvine a. e. tel: 949.789.4100 b. m. tel: 949.470.2900 i. e. tel: 949.727.3291 w. e. tel: 800.626.9953 los angeles a. e. tel: 818.594.0404 w. e. tel: 800.288.9953 sacramento a. e. tel: 916.632.4500 w. e. tel: 800.627.9953 san diego a. e. tel: 858.385.7500 b. m. tel: 858.597.3010 i. e. tel: 800.677.6011 w. e. tel: 800.829.9953 san jose a. e. tel: 408.435.3500 b. m. tel: 408.436.0881 i. e. tel: 408.952.7000 santa clara w. e. tel: 800.866.9953 woodland hills a. e. tel: 818.594.0404 westlake village i. e. tel: 818.707.2101 colorado denver a. e. tel: 303.790.1662 b. m. tel: 303.846.3065 w. e. tel: 800.933.9953 englewood i. e. tel: 303.649.1800 idaho springs b. m. tel: 303.567.0703 connecticut cheshire a. e. tel: 203.271.5700 i. e. tel: 203.272.5843 wallingford w. e. tel: 800.605.9953 delaware north/south a. e. tel: 800.526.4812 tel: 800.638.5988 b. m. tel: 302.328.8968 w. e. tel: 856.439.9110 florida altamonte springs b. m. tel: 407.682.1199 i. e. tel: 407.834.6310 boca raton i. e. tel: 561.997.2540 bonita springs b. m. tel: 941.498.6011 clearwater i. e. tel: 727.524.8850 fort lauderdale a. e. tel: 954.484.5482 w. e. tel: 800.568.9953 miami b. m. tel: 305.477.6406 orlando a. e. tel: 407.657.3300 w. e. tel: 407.740.7450 tampa w. e. tel: 800.395.9953 st. petersburg a. e. tel: 727.507.5000 georgia atlanta a. e. tel: 770.623.4400 b. m. tel: 770.980.4922 w. e. tel: 800.876.9953 duluth i. e. tel: 678.584.0812 hawaii a. e. tel: 800.851.2282 idaho a. e. tel: 801.365.3800 w. e. tel: 801.974.9953 illinois north/south a. e. tel: 847.797.7300 tel: 314.291.5350 chicago b. m. tel: 847.413.8530 w. e. tel: 800.853.9953 schaumburg i. e. tel: 847.885.9700 indiana fort wayne i. e. tel: 219.436.4250 w. e. tel: 888.358.9953 indianapolis a. e. tel: 317.575.3500 iowa w. e. tel: 612.853.2280 cedar rapids a. e. tel: 319.393.0033 kansas w. e. tel: 303.457.9953 kansas city a. e. tel: 913.663.7900 lenexa i. e. tel: 913.492.0408 kentucky w. e. tel: 937.436.9953 central/northern/ western a. e. tel: 800.984.9503 tel: 800.767.0329 tel: 800.829.0146 louisiana w. e. tel: 713.854.9953 north/south a. e. tel: 800.231.0253 tel: 800.231.5775 maine a. e. tel: 800.272.9255 w. e. tel: 781.271.9953 maryland baltimore a. e. tel: 410.720.3400 w. e. tel: 800.863.9953 columbia b. m. tel: 800.673.7461 i. e. tel: 410.381.3131 massachusetts boston a. e. tel: 978.532.9808 w. e. tel: 800.444.9953 burlington i. e. tel: 781.270.9400 marlborough b. m. tel: 800.673.7459 woburn b. m. tel: 800.552.4305 michigan brighton i. e. tel: 810.229.7710 detroit a. e. tel: 734.416.5800 w. e. tel: 888.318.9953 clarkston b. m. tel: 877.922.9363 minnesota champlin b. m. tel: 800.557.2566 eden prairie b. m. tel: 800.255.1469 minneapolis a. e. tel: 612.346.3000 w. e. tel: 800.860.9953 st. louis park i. e. tel: 612.525.9999 mississippi a. e. tel: 800.633.2918 w. e. tel: 256.830.1119 missouri w. e. tel: 630.620.0969 st. louis a. e. tel: 314.291.5350 i. e. tel: 314.872.2182 montana a. e. tel: 800.526.1741 w. e. tel: 801.974.9953 nebraska a. e. tel: 800.332.4375 w. e. tel: 303.457.9953 nevada las vegas a. e. tel: 800.528.8471 w. e. tel: 702.765.7117 new hampshire a. e. tel: 800.272.9255 w. e. tel: 781.271.9953 new jersey north/south a. e. tel: 201.515.1641 tel: 609.222.6400 mt. laurel i. e. tel: 856.222.9566 pine brook b. m. tel: 973.244.9668 w. e. tel: 800.862.9953 parsippany i. e. tel: 973.299.4425 wayne w. e. tel: 973.237.9010 new mexico w. e. tel: 480.804.7000 albuquerque a. e. tel: 505.293.5119 u.s. distributors by state (continued) new york hauppauge i. e. tel: 516.761.0960 long island a. e. tel: 516.434.7400 w. e. tel: 800.861.9953 rochester a. e. tel: 716.475.9130 i. e. tel: 716.242.7790 w. e. tel: 800.319.9953 smithtown b. m. tel: 800.543.2008 syracuse a. e. tel: 315.449.4927 north carolina raleigh a. e. tel: 919.859.9159 i. e. tel: 919.873.9922 w. e. tel: 800.560.9953 north dakota a. e. tel: 800.829.0116 w. e. tel: 612.853.2280 ohio cleveland a. e. tel: 216.498.1100 w. e. tel: 800.763.9953 dayton a. e. tel: 614.888.3313 i. e. tel: 937.253.7501 w. e. tel: 800.575.9953 strongsville b. m. tel: 440.238.0404 valley view i. e. tel: 216.520.4333 oklahoma w. e. tel: 972.235.9953 tulsa a. e. tel: 918.459.6000 i. e. tel: 918.665.4664 oregon beaverton b. m. tel: 503.524.1075 i. e. tel: 503.644.3300 portland a. e. tel: 503.526.6200 w. e. tel: 800.879.9953 pennsylvania mercer i. e. tel: 412.662.2707 philadelphia a. e. tel: 800.526.4812 b. m. tel: 877.351.2355 w. e. tel: 800.871.9953 pittsburgh a. e. tel: 412.281.4150 w. e. tel: 440.248.9996 rhode island a. e. 800.272.9255 w. e. tel: 781.271.9953 south carolina a. e. tel: 919.872.0712 w. e. tel: 919.469.1502 south dakota a. e. tel: 800.829.0116 w. e. tel: 612.853.2280 tennessee w. e. tel: 256.830.1119 east/west a. e. tel: 800.241.8182 tel: 800.633.2918 texas arlington b. m. tel: 817.417.5993 austin a. e. tel: 512.219.3700 b. m. tel: 512.258.0725 i. e. tel: 512.719.3090 w. e. tel: 800.365.9953 dallas a. e. tel: 214.553.4300 b. m. tel: 972.783.4191 w. e. tel: 800.955.9953 el paso a. e. tel: 800.526.9238 houston a. e. tel: 713.781.6100 b. m. tel: 713.917.0663 w. e. tel: 800.888.9953 richardson i. e. tel: 972.783.0800 rio grande valley a. e. tel: 210.412.2047 stafford i. e. tel: 281.277.8200 utah centerville b. m. tel: 801.295.3900 murray i. e. tel: 801.288.9001 salt lake city a. e. tel: 801.365.3800 w. e. tel: 800.477.9953 vermont a. e. tel: 800.272.9255 w. e. tel: 716.334.5970 virginia a. e. tel: 800.638.5988 w. e. tel: 301.604.8488 haymarket b. m. tel: 703.754.3399 spring?ld b. m. tel: 703.644.9045 washington kirkland i. e. tel: 425.820.8100 maple valley b. m. tel: 206.223.0080 seattle a. e. tel: 425.882.7000 w. e. tel: 800.248.9953 west virginia a. e. tel: 800.638.5988 wisconsin milwaukee a. e. tel: 414.513.1500 w. e. tel: 800.867.9953 wauwatosa i. e. tel: 414.258.5338 wyoming a. e. tel: 800.332.9326 w. e. tel: 801.974.9953 sales of?es and design resource centers lsi logic corporation corporate headquarters 1551 mccarthy blvd milpitas ca 95035 tel: 408.433.8000 fax: 408.433.8989 north america california irvine 18301 von karman ave suite 900 irvine, ca 92612 ? tel: 949.809.4600 fax: 949.809.4444 pleasanton design center 5050 hopyard road, 3rd floor suite 300 pleasanton, ca 94588 tel: 925.730.8800 fax: 925.730.8700 san diego 7585 ronson road suite 100 san diego, ca 92111 tel: 858.467.6981 fax: 858.496.0548 silicon valley 1551 mccarthy blvd sales of?e m/s c-500 milpitas, ca 95035 ? tel: 408.433.8000 fax: 408.954.3353 design center m/s c-410 tel: 408.433.8000 fax: 408.433.7695 wireless design center 11452 el camino real suite 210 san diego, ca 92130 tel: 858.350.5560 fax: 858.350.0171 colorado boulder 4940 pearl east circle suite 201 boulder, co 80301 ? tel: 303.447.3800 fax: 303.541.0641 colorado springs 4420 arrowswest drive colorado springs, co 80907 tel: 719.533.7000 fax: 719.533.7020 fort collins 2001 dan?ld court fort collins, co 80525 tel: 970.223.5100 fax: 970.206.5549 florida boca raton 2255 glades road suite 324a boca raton, fl 33431 tel: 561.989.3236 fax: 561.989.3237 georgia alpharetta 2475 north winds parkway suite 200 alpharetta, ga 30004 tel: 770.753.6146 fax: 770.753.6147 illinois oakbrook terrace two mid american plaza suite 800 oakbrook terrace, il 60181 tel: 630.954.2234 fax: 630.954.2235 kentucky bowling green 1262 chestnut street bowling green, ky 42101 tel: 270.793.0010 fax: 270.793.0040 maryland bethesda 6903 rockledge drive suite 230 bethesda, md 20817 tel: 301.897.5800 fax: 301.897.8389 massachusetts waltham 200 west street waltham, ma 02451 ? tel: 781.890.0180 fax: 781.890.6158 burlington - mint technology 77 south bedford street burlington, ma 01803 tel: 781.685.3800 fax: 781.685.3801 minnesota minneapolis 8300 norman center drive suite 730 minneapolis, mn 55437 ? tel: 612.921.8300 fax: 612.921.8399 new jersey red bank 125 half mile road suite 200 red bank, nj 07701 tel: 732.933.2656 fax: 732.933.2643 cherry hill - mint technology 215 longstone drive cherry hill, nj 08003 tel: 856.489.5530 fax: 856.489.5531 new york fairport 550 willowbrook of?e park fairport, ny 14450 tel: 716.218.0020 fax: 716.218.9010 north carolina raleigh phase ii 4601 six forks road suite 528 raleigh, nc 27609 tel: 919.785.4520 fax: 919.783.8909 oregon beaverton 15455 nw greenbrier parkway suite 235 beaverton, or 97006 tel: 503.645.0589 fax: 503.645.6612 texas austin 9020 capital of tx highway north building 1 suite 150 austin, tx 78759 tel: 512.388.7294 fax: 512.388.4171 plano 500 north central expressway suite 440 plano, tx 75074 ? tel: 972.244.5000 fax: 972.244.5001 houston 20405 state highway 249 suite 450 houston, tx 77070 tel: 281.379.7800 fax: 281.379.7818 canada ontario ottawa 260 hearst way suite 400 kanata, on k2l 3h1 ? tel: 613.592.1263 fax: 613.592.3253 international france paris lsi logic s.a. immeuble europa 53 bis avenue de l'europe b.p. 139 78148 velizy-villacoublay cedex, paris ? tel: 33.1.34.63.13.13 fax: 33.1.34.63.13.19 germany munich lsi logic gmbh orleansstrasse 4 81669 munich ? tel: 49.89.4.58.33.0 fax: 49.89.4.58.33.108 stuttgart mittlerer pfad 4 d-70499 stuttgart ? tel: 49.711.13.96.90 fax: 49.711.86.61.428 italy milan lsi logic s.p.a. centro direzionale colleoni palazzo orione ingresso 1 20041 agrate brianza, milano ? tel: 39.039.687371 fax: 39.039.6057867 japan tokyo lsi logic k.k. rivage-shinagawa bldg. 14f 4-1-8 kounan minato-ku, tokyo 108-0075 ? tel: 81.3.5463.7821 fax: 81.3.5463.7820 osaka crystal tower 14f 1-2-27 shiromi chuo-ku, osaka 540-6014 ? tel: 81.6.947.5281 fax: 81.6.947.5287 sales of?es and design resource centers (continued) korea seoul lsi logic corporation of korea ltd 10th fl., haesung 1 bldg. 942, daechi-dong, kangnam-ku, seoul, 135-283 tel: 82.2.528.3400 fax: 82.2.528.2250 the netherlands eindhoven lsi logic europe ltd world trade center eindhoven building ?ijder bogert 26 5612 lz eindhoven tel: 31.40.265.3580 fax: 31.40.296.2109 singapore singapore lsi logic pte ltd 7 temasek boulevard #28-02 suntec tower one singapore 038987 tel: 65.334.9061 fax: 65.334.4749 sweden stockholm lsi logic ab finlandsgatan 14 164 74 kista ? tel: 46.8.444.15.00 fax: 46.8.750.66.47 taiwan taipei lsi logic asia, inc. taiwan branch 10/f 156 min sheng e. road section 3 taipei, taiwan r.o.c. tel: 886.2.2718.7828 fax: 886.2.2718.8869 united kingdom bracknell lsi logic europe ltd greenwood house london road bracknell, berkshire rg12 2ub ? tel: 44.1344.426544 fax: 44.1344.481039 ? sales of?es with design resource centers international distributors australia new south wales reptechnic pty ltd 3/36 bydown street neutral bay, nsw 2089 ? tel: 612.9953.9844 fax: 612.9953.9683 belgium acal nv/sa lozenberg 4 1932 zaventem tel: 32.2.7205983 fax: 32.2.7251014 china beijing lsi logic international services inc. beijing representative of?e room 708 canway building 66 nan li shi lu xicheng district beijing 100045, china tel: 86.10.6804.2534 to 38 fax: 86.10.6804.2521 france rungis cedex azzurri technology france 22 rue saarinen sillic 274 94578 rungis cedex tel: 33.1.41806310 fax: 33.1.41730340 germany haar ebv elektronik hans-pinsel str. 4 d-85540 haar tel: 49.89.4600980 fax: 49.89.46009840 munich avnet emg gmbh stahlgruberring 12 81829 munich tel: 49.89.45110102 fax: 49.89.42.27.75 wuennenberg-haaren peacock ag graf-zepplin-str 14 d-33181 wuennenberg-haaren tel: 49.2957.79.1692 fax: 49.2957.79.9341 hong kong hong kong avt industrial ltd unit 608 tower 1 cheung sha wan plaza 833 cheung sha wan road kowloon, hong kong tel: 852.2428.0008 fax: 852.2401.2105 serial system (hk) ltd 2301 nanyang plaza 57 hung to road, kwun tong kowloon, hong kong tel: 852.2995.7538 fax: 852.2950.0386 india bangalore spike technologies india private ltd 951, vijayalakshmi complex, 2nd floor, 24th main, j p nagar ii phase, bangalore, india 560078 ? tel: 91.80.664.5530 fax: 91.80.664.9748 israel tel aviv eastronics ltd 11 rozanis street p.o. box 39300 tel aviv 61392 tel: 972.3.6458777 fax: 972.3.6458666 japan tokyo daito electron sogo kojimachi no.3 bldg 1-6 kojimachi chiyoda-ku, tokyo 102-8730 tel: 81.3.3264.0326 fax: 81.3.3261.3984 global electronics corporation nichibei time24 bldg. 35 tansu-cho shinjuku-ku, tokyo 162-0833 tel: 81.3.3260.1411 fax: 81.3.3260.7100 technical center tel: 81.471.43.8200 marubeni solutions 1-26-20 higashi shibuya-ku, tokyo 150-0001 tel: 81.3.5778.8662 fax: 81.3.5778.8669 shinki electronics myuru daikanyama 3f 3-7-3 ebisu minami shibuya-ku, tokyo 150-0022 tel: 81.3.3760.3110 fax: 81.3.3760.3101 yokohama-city innotech 2-15-10 shin yokohama kohoku-ku yokohama-city, 222-8580 tel: 81.45.474.9037 fax: 81.45.474.9065 macnica corporation hakusan high-tech park 1-22-2 hadusan, midori-ku, yokohama-city, 226-8505 tel: 81.45.939.6140 fax: 81.45.939.6141 the netherlands eindhoven acal nederland b.v. beatrix de rijkweg 8 5657 eg eindhoven tel: 31.40.2.502602 fax: 31.40.2.510255 switzerland brugg lsi logic sulzer ag mattenstrasse 6a ch 2555 brugg tel: 41.32.3743232 fax: 41.32.3743233 taiwan taipei avnet-mercuries corporation, ltd 14f, no. 145, sec. 2, chien kuo n. road taipei, taiwan, r.o.c. tel: 886.2.2516.7303 fax: 886.2.2505.7391 lumax international corporation, ltd 7th fl., 52, sec. 3 nan-kang road taipei, taiwan, r.o.c. tel: 886.2.2788.3656 fax: 886.2.2788.3568 prospect technology corporation, ltd 4fl., no. 34, chu luen street taipei, taiwan, r.o.c. tel: 886.2.2721.9533 fax: 886.2.2773.3756 wintech microeletronics co., ltd 7f., no. 34, sec. 3, pateh road taipei, taiwan, r.o.c. tel: 886.2.2579.5858 fax: 886.2.2570.3123 united kingdom maidenhead azzurri technology ltd 16 grove park business estate waltham road white waltham maidenhead, berkshire sl6 3lw tel: 44.1628.826826 fax: 44.1628.829730 milton keynes ingram micro (uk) ltd garamonde drive wymbush milton keynes buckinghamshire mk8 8df tel: 44.1908.260422 swindon ebv elektronik 12 interface business park bincknoll lane wootton bassett, swindon, wiltshire sn4 8sy tel: 44.1793.849933 fax: 44.1793.859555 ? sales of?es with design resource centers |
Price & Availability of ARM966E-S
 |
|
|
|
|
All Rights Reserved © IC-ON-LINE 2003 - 2022 |
| [Add Bookmark] [Contact Us] [Link exchange] [Privacy policy] |
|
Mirror Sites : [www.datasheet.hk]
[www.maxim4u.com] [www.ic-on-line.cn]
[www.ic-on-line.com] [www.ic-on-line.net]
[www.alldatasheet.com.cn]
[www.gdcy.com]
[www.gdcy.net] |